Tanchiki in the console, article four: "The new server - the new protocol"

Good afternoon, dear readers. We were at WorldSkills (to which I will dedicate a separate article), in connection with which this publication has not been written for a long time, just as the server has not been updated.

Today I will talk about an unexpected idea and a small analysis of network protocols. Details under the cut.

So, let's start with the TCP / IP protocol. What is good about this protocol: a secure connection that ensures integrity in packet delivery, reliability and security. I also thought so for a long time, until the terrible happened ... at a certain stage of work, I fell off a virtual machine (ie, a client) and the server was fixated on myself. He simply sent himself packets to one port, received something else, folded the packet + packet (that is, literally, added the beginning data of the second and sometimes all the second data to the end of the first one) and sent it to the receiving port, then received , then sent it back to itself and it very much eaten resources (from the word 100%).

Having decided to find answers on the Internet, I finally didn’t find the answers and, having become disillusioned with this protocol, I began asking my friend for help in creating a new protocol based on UDP.
')

Part 1: Server Changes

Before moving on to the UDP protocol, I want to talk about the changes on the server:

1. It was implemented normal raspotochivanie customers (which was not possible earlier).
2. Added a more adequate (in my opinion) model of interaction with customers.

Immediately I’m going to the second point, because having realized it, I was able to achieve the first one. I used to foolishly create a thread that creates a thread that creates threads and sends messages to everyone ... it was not right at the root. At the moment, everything works according to this scheme:



Perhaps this is the most adequate interaction model that was pulled out of my head.
Both at reception, and at sending connection is not broken, and copied and sent.

The interaction takes place according to the principle: heard-sent. There is not any conversion or verification of data, but periodically checking for the viability of the client (so that we do not go into an eternal cycle). This happens according to the set parameter - the number of reads executed (how many times we have heard messages from the client).

If he reaches the desired mark, then a message is sent to the client asking if he is alive.

match item.stream.write(b"you") { Ok(ok) => {}, Err(e) => {/*    */ break;} , }; 

And if we accept a non-zero message from it, then we end the check and listen as before.

  let mut buf_q:[u8; 256] = [0; 256]; let mut buf_q_else: [u8; 128] = [0; 128]; let mut recv_val = false; let mut b_false_true = false; loop { item.stream.read(&mut buf_q); if buf_q.starts_with(&buf_q_else) { recv_val = recv_.recv().unwrap(); if recv_val == true { b_false_true = true; break; } } } if b_false_true == true { break;} /*      loop ,           */ 

We listen to customers

  item.stream.read(&mut buf); println!("  [{:?}]", item.stream); if buf.starts_with(&q) == false { sender_clone.send(buf).unwrap(); } /*  q -    (          ) */ 

Next, I implemented the removal of clients from reading (if the message did not come), but now we will not talk about this (you can learn more about how everything works in the comments to the changes on my githaba), I want to go to a deeper analysis of network protocols, because what we did on our WorldSkills trip (in our free time).

Part 2: A Brief Theory of Network Protocols

I will not analyze the wilds of the OSI system, but I will say the following - there are two types of transport network protocols (on which all the others are built):

1st TCP / IP
2nd UDP / IP

That the first, as the second are under construction on the IP protocol (therefore and there is '/ IP').
We will discuss the pros and cons of both

TCP / IP

+ sending packages one by one
+ basic encryption (random number method)
+ re-request in case of packet distortion
+ - small shipments

- slow speed
- triple handshake on connect and double delivery confirmation
- A lot of other errors that are not visible at first glance (I ran into one of them)

UDP / IP

+ speed
+ - independence (do not care if the package reached)
+ - the package is not divided into small portions
+ there is no handshake in principle
+ - there are no errors (there are no their definitions, the packet just erupts from the outside and flies ... where its byte eyes are looking)

- no order
- possible distortion (because there is no verification)
- no encryption

There are also many other protocols based on these protocols, but for me the speed was important, not the convenience of perception / additional functions.

Chapter 3: “Building a Model and Summing Up”

Let's start from the beginning: what do we want?

1. Stable client connection (TCP)
2. High data rate (UDP)
3. High speed initial connection (UDP)
4. Understanding how it works
5. There should be no distortion and ordering should be (TCP)

Two TCP and two UDP properties. Was it worth one mistake in TCP (currently fixed in the project) creating a TCP similarity but with its own problems? My answer is yes!

Why yes? Climbing on the forums, I realized that TCP is a case of UDP, and TCP has a lot of errors that are missing in UDP (due to the fact that UDP sends and forgets).

Package Data Structure



The scheme of the server operation on the future protocol in this image:



Thus, we get a simple scheme of work, the client connects - we transfer it to the general timeout, and each time we send a message, we wait for confirmation of acceptance by the client, while working with other clients.

The disadvantages of this solution are the lack of encryption (which we will finish at the client) and unpredictable behavior in the absence of displaying errors on the screen.

Theoretically, it turned out the same bike as on TCP, only without a triple handshake and without dividing packets into small portions, which I consider to be a victory.

You can see it very soon in my githaba .

Thanks for reading and all the best for you!