Differences between connectionless and connection-oriented protocols in Linux Network Programming

Differences between connectionless and connection-oriented protocols in Linux Network Programming

The most basic concepts in network programming are connection-oriented and connectionless protocols. Although the difference between the two is essentially not difficult to understand, it is very confusing for those who have just begun network programming. This problem is related to the context. Obviously, if two computers need to communicate, they must "Connect" in some form. What does "connectionless communication" mean?

The answer is: connection-oriented and connectionless refer to protocols. That is to say, these terms refer not to physical media, but to instructions on how to transmit data on physical media. Connection-oriented and connectionless protocols are acceptable, and the same physical media is usually shared.

What is the difference between the two and the physical medium that carries the data?The essential difference between them is that for the connectionless protocol, the processing of each group is independent of all other groups, and for the connection-oriented protocol, the Protocol maintains the status information related to the successor group.

A group in the connectionless protocol is called a data packet. Each group is individually addressable and sent by an application. From the Protocol perspective, each datagram is an independent entity, and it has nothing to do with any other datagram transmitted between two identical peer entities, this means that the Protocol is likely to be unreliable. That is to say, the network will try its best to transmit every datagram, but it does not guarantee that the datagram will not be lost, there will be no delay or good sequence transmission.

On the other hand, connection-oriented protocols maintain the status between groups. Applications using this Protocol usually have long-term conversations. With these statuses in mind, the protocol can provide reliable transmission. For example, the sender can remember which data has been sent but has not been confirmed, and when the data was sent. If no confirmation is received within a certain interval, the sender can re-transmit the data. The receiving end can remember what data has been received and discard the duplicate data. If the group does not arrive in order, the acceptor can save it until the group arrives logically before it.

A typical connection-oriented protocol has three phases. In the first stage, establish connections between peer entities. The next step is the data transmission phase. In this phase, data is transmitted between equal entities. Finally, when the peer object completes data transmission, the connection is removed.

A standard analogy is that using a connectionless protocol is like sending a message, and using a connection-oriented protocol is like making a call.

When sending a message to a friend, each letter is an independently addressable and self-contained entity. The post office will not take into account any other correspondence between the two communications. The post office will not maintain the historical records of previous contacts-that is, it will not maintain the status between letters. The post office does not guarantee that letters are not lost, delayed, or sorted properly. This method corresponds to the method in which no connection protocol sends data packets. (The analogy with postcards is more appropriate, because letters with wrong addresses will be returned to the sender, and postcards (the same as the typical connectionless protocol datagram) will not .)

Now let's take a look at what will happen when I call instead of sending messages to my friends.

First, call a friend's number. A friend replied, saying "hi" or something, and then we responded: "Hi, Lucy. I'm Mike ." We chatted with our friends for a while and then said goodbye and hung up. This is a typical situation in connection-oriented protocols. In the connection establishment phase, one end is connected to its peer entity to exchange initial greeting information, communicate some parameters and options used in the session, and then connect to the data transmission phase.

During the conversation, users at both ends know who they are talking to, so there is no need to keep saying "this is what Mike is talking to Lucy ". There is no need to call a friend's phone number before every conversation-our phone number is connected. Similarly, in the connection-oriented data transmission phase, there is no need to describe the addresses of ourselves or our peers. These addresses are included in the status maintained by the connection. We only need to send data and do not need to consider addressing or other protocol-related issues.

Just like a telephone conversation, when any end of the connection completes data transmission, it must notify its peer-to-peer entities. When both ends are transmitted, the connection must be removed in sequence.

Since no connection protocol has so many shortcomings, we may wonder why we need to use this protocol? We can see that in many cases, it makes sense to build an application using the connectionless protocol. For example, the connectionless protocol can easily support one-to-many and multi-to-one communication, while connection-oriented protocols usually require multiple independent connections. But more importantly, the connectionless protocol is the basis for building connection-oriented protocols. TCP/IP is a layer-4 protocol stack, as shown in:

, Both TCP and UDP are built on the IP address. Therefore, IP is the basis for building the entire TCP/IP protocol family. However, IP addresses provide a dedicated and unreliable connection-free service. It receives groups from its upper layer, encapsulates them in an IP group, selects the correct hardware interface for the group based on the route, and sends the group from this interface. Once the group is sent, the IP address no longer cares about the group. Like all the connectionless protocols, the group is no longer remembered after the group is sent.

This simplicity is also the main advantage of IP. Because it has no assumptions about the underlying physical media, IP addresses can be run on any physical link that can carry groups. For example, an IP can run on a simple serial link, an Ethernet and a licensing ring LAN, X.25, and WAN, CDPD (Cellular Digital Packet Data) using an ATM (Asychronous Transfer Mode, wireless Cellular Digital grouping data) network, and many other networks. Although there are many differences between these network technologies, IP addresses treat them equally without making any assumptions except that they can be forwarded to groups. This mechanism implies a deep meaning. IP can run on any network that can carry groups, so the entire TCP/IP protocol family can also.

Now let's take a look at how TCP uses this simple connectionless service to provide reliable connection-oriented services. A tcp group is called a segment and is sent in an IP datagram. Therefore, it cannot be assumed that these groups will arrive at the destination, let alone ensure that the group is not damaged and has arrived in the original order.

To provide this reliability, TCP adds three functions to the basic IP service:

First, it provides a checksum for the data in the TCP segment. This helps ensure that data arriving at the destination is not damaged by the network during transmission.

Second, it allocates a serial number for each byte, so that if the data arrives at the destination in an incorrect order, the receiver can reload it in the appropriate order. Of course, TCP does not append a serial number to each byte. In fact, the header of each TCP segment contains the serial number of the first byte in the segment. In this way, the serial number of other bytes in the segment is implicitly known.

Third, TCP provides a validation-retransmission mechanism to ensure that each segment is finally transmitted.

On the other hand, UDP provides an unreliable connectionless service for programmers who write applications. In fact, UDP only adds two functions to the underlying IP protocol.

First, it provides an optional checksum to detect data corruption. Although the IP address also has a Checksum, it only calculates the IP address group header. Therefore, both TCP and UDP provide checksum to protect their own headers and data.

Second, the port concept is the second feature that UDP adds to the IP address.

Back to the analogy with telephone/mail, we can regard the network address in the TCP connection as the phone number of an office switchboard, and regard the port number as the extension number of a specific phone number being called in the office. Similarly, you can use the UDP network address as the address of an apartment building and the port number as the personal mailbox in the apartment building Hall.