Linux Network Programming-the difference between non-connected and connection-oriented protocols

The most basic concepts in network programming are connection-oriented (connection-oriented) and non-connected (connectionless) protocols. In essence, the difference between the two is not difficult to understand, but for those who are just beginning to network programming, it is a very confusing problem. The problem is somewhat related to the context: Obviously, if two computers are to communicate, they must be "connected" in some form, what does "no connection communication" mean?

The answer is: connection-oriented and no-connection refers to the protocol. in other words, these terms refer not to the physical media itself, but to how the data is transferred on the physical medium. Connection-oriented and no-connection protocols can, and often do, share the same physical medium.

What if the difference between the two is irrelevant to the physical media that hosts the data? The essential difference between them is that for a non-connection protocol, each packet is handled independently of all other groupings, whereas for a connection-oriented protocol, the Protocol implementation maintains the state information related to the successor group.

A packet in a no-connection protocol is called a datagram (datagram), and each grouping is addressed independently and sent by the application. from an agreement point of view, each datagram is a separate entity that has no relation to any other datagram transmitted between the two identical peer entities . This means that the agreement is likely to be unreliable. in other words, the network will do its best to transmit every datagram, but does not guarantee that the datagram is not lost, not delayed or good sequential transmission.

On the other hand, connection-oriented protocols maintain the state between groupings, and applications that use such protocols often have long-term conversations. With these states in mind, protocols can provide reliable transmission. For example, the sender can remember which data has been sent out but not yet confirmed, and when the data was sent. If no acknowledgement is received within a certain time interval, the sender can retransmit the data. The receiving end can remember what data has been received and discard the duplicated data. If the grouping does not arrive sequentially, the receiving side can save it until it is logically preceded by its packet arrival.

There are three phases to a typical connection-oriented protocol. In the first phase, a connection is established between peer entities. The next step is the data transfer phase, where it is transmitted between peer entities. Finally, when the peer entity completes the data transfer, the connection is removed.

One standard analogy is that using a no-connection protocol is like sending a letter , while using a connection-oriented protocol is like making a phone call.

When sending letters to a friend, each letter is an individually addressable and self-contained entity. The Post Office does not take into account any other correspondence between the two communications persons when dealing with these letters. The Post Office does not maintain the historical record of the previous communicator-that is, it does not maintain the state between the letters. The Post Office also does not guarantee that the letter is not lost, not delayed, good order. This method corresponds to the way the datagram is sent without a connection protocol. (It would be more appropriate to use a postcard to make an analogy, because a letter with a wrong address will be returned to the sender, and a postcard (as with a typical non-connected protocol datagram) will not. ）

Now it's not about sending a letter to a friend, it's about what happens when you make a phone call.

First, dial a friend's number to initiate the call. A friend answers, says "Hi", and then we respond: "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 that occurs in a connection-oriented protocol . During the connection establishment phase, one end contacts the peer entity, exchanges the initial greeting information, communicates some parameters and options to be used in the session, and then connects to the data transfer phase.

During the phone conversation, both users know who they're talking to, so there's no need to keep saying "This is Mike talking to Lucy." There's no need to dial a friend's phone number once before each speech-our phone is connected. Similarly, there is no need to specify the address of ourselves or the peer entity in the data transfer phase of the connection-oriented protocol. These addresses are included in the status that the connection maintains for us. We just have to send the data, and we don't need to consider addressing or other protocol-related issues.

Just as with a telephone conversation, the peer entity is notified when either end of the connection completes the transmission of the data. When both ends are transferred, the connection is removed in turn.

since there are so many drawbacks to a non-connectivity protocol, you might wonder why you should use such a protocol. we will see that in many cases it makes sense to build applications using a non-connectivity protocol. For example, using a no-connection protocol can easily support one-to-many and multi-pair communication, whereas a connection-oriented protocol usually requires multiple independent connections. But more importantly, the non-connectivity protocol is the basis for building a connection-oriented protocol. TCP/IP is based on a 4-tier protocol stack, as shown in:

, both TCP and UDP are built on top of the IP. Therefore, IP is the basis for building the entire TCP/IP protocol family. But IP provides a best-effort, unreliable, non-connected service. It receives packets from its upper layer, encapsulates them in an IP packet, selects the correct hardware interface for grouping according to routing, and sends packets out from this interface. Once the packet is sent out, IP will no longer care about this grouping. As with all non-connection protocols, it will not remember this grouping until it is sent in groups.

This simplicity is also the main advantage of IP . Because it makes no assumptions about the underlying physical media, IP can be run on any physical link that can host the packet. For example, IP can run on simple serial links, Ethernet and Token Ring LANs, X. and WANs using ATM (asychronous Transfer mode, asynchronous transfer mode), CDPD (Cellular Digital Packet Data, Wireless cellular digital Packet data) network, as well as many other networks. Although there are significant differences between these network technologies, IP treats them equally, without making any assumptions about them except that they can be forwarded for grouping. This mechanism implies deep meaning. IP can be run on any network that can host the packet, so the entire TCP/IP protocol family is also available.

Now let's take a look at how TCP uses this simple, non-connected service to provide a reliable connection-oriented service. The grouping of TCP is called segment (segment), which is sent in an IP datagram, so it is not possible to assume that these groupings will arrive at the destination, let alone ensure that the groupings are undamaged and arrive in the original order.

to provide this reliability, TCP adds three features 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 assigns a sequence number to each byte, so that if the data arrives at the destination in a really wrong order, the receiving side can also reload it in the proper order. Of course, TCP does not have a serial number attached to each byte. In fact, the header of each TCP segment contains the sequence number of the first byte in the segment. In this way, the sequence number of the other bytes in the segment is implicitly known.
Third , TCP provides a confirmation-retransmission mechanism to ensure that eventually each segment will be routed.

UDP, on the other hand, provides an unreliable, non-connected service for programmers who write applications . In fact, UDP adds only two features to the underlying IP protocol.

First , it provides an optional checksum to detect the corruption of the data. Although IP also has checksums, it calculates only the IP packet header, so TCP and UDP also provide checksums to protect their own headers and data.

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

Back to the phone/letter analogy, we can treat the network address in the TCP connection as the telephone number of an office switchboard, and the port number as the extension number of a particular phone that is being called in the office. Similarly, the UDP network address can be used as the address of an apartment building, and the port number as a personal mailbox in the apartment building lobby.

Linux Network Programming-the difference between non-connected and connection-oriented protocols