Linux Network Programming--there is no difference between a connection and a connection-oriented protocol

The most important concept in network programming is the connection orientation (connection-oriented) and the non-connected (connectionless) protocol. Though the essence. The difference between the two is not difficult to understand, programming people, but it is a very easy to confuse the problem.

The problem is somewhat related to the context: obviously. If two computers are to communicate, they must be "connected" in some way. 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. It is used to illustrate how data is transferred on physical media. Connection-oriented and no-connection protocols can, and often do, share the same physical medium.

Suppose the difference between the two is not related to the physical medium that carries the data, and what about it? The essential difference is that for a non-connection protocol, each packet is handled independently of all other groupings, and for connection-oriented protocols. The protocol implementation maintains the status information related to subsequent groupings.

A packet in a no-Connection Agreement is called a datagram (datagram). Each grouping is an independent addressing. and sent by the application. from the point of view of the agreement. Each datagram is a separate entity that is not related to any other datagram transmitted between the two same peer entities, which means that the protocol is very likely to be unreliable. that means. The network will do its best to transmit every datagram. However, there is no guarantee that the datagram is not lost, delayed or well sequenced.

On the other hand, the connection-oriented protocol maintains the state between the groupings. Applications that use such protocols often have long-term conversations. Remember these states. The protocol is capable of providing reliable transmission. For example, the sender can remember which data has been sent out but has not yet been confirmed. And when the data was sent.

Assume that no acknowledgement was received within a certain interval. The sender can retransmit the data.

The receiving end can remember what data has been received. and discard the repeated data. Assuming that the grouping does not arrive sequentially, the receiving side is able to save it until logically before its grouping arrives.

There are three phases to a typical connection-oriented protocol. In the first phase, a connection is established between peer entities. Next is the transfer data phase, in which the data is transferred between peer entities. Finally, when the peer entity is finished transmitting data. The connection was removed.

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

When sending letters to a friend, each letter is an individually addressable entity that is self-contained.

The Post Office does not take into account any other correspondence between the two communication providers 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. The way in which the datagram is sent is corresponding to the no-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 (as with a typical no-connect protocol datagram) postcards do not. ）

Now come and see not sending a letter to a friend. It's about what happens when you make a phone call.

First of all. Dial a friend's number to initiate a call. A friend responds and says "hi" or something like that. 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 that occurs in a connection-oriented protocol . During the connection establishment phase, one end contacts the peer entity, exchanging the initial greeting information, and communicating some of the parameters and options to be used in the session. The connection then enters the transmit data phase.

In the process of telephone conversation. Users at both ends know who they're talking to, so it's not necessary to keep saying "This is Mike talking to Lucy." It's not necessary to dial a friend's phone number once before each speech-our phone is connected. Similarly. It is also not necessary to describe the address of ourselves or the peer entity in the transfer data phase of the connection-oriented protocol. These addresses are included in the status that the connection maintains for us. We just need to send the data, no need to consider addressing or other protocol-related issues.

It's like talking on the phone. When either end of the connection finishes transmitting the data, it is notified to its peer entity. When both ends are transferred, the connection is removed in turn.

since there are so many drawbacks to the no-connection protocol, you might be surprised. Why use such a protocol? we'll see. In very many cases, it is meaningful to build applications using a no-connection protocol. For example, using a no-connection protocol can be very convenient to support one-to-many and multi-pair communication. The connection-oriented protocol usually requires multiple independent connection talents. 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, for example, as seen in:

As you can see, 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 the groupings from its upper layer, encapsulates them in an IP packet, and selects the correct hardware interface based on routing for grouping. The packet is sent out from this interface. Once the packet is sent out, IP will no longer care about this grouping. The same as all non-connected protocols. It will not remember the grouping after it has been sent out in groups.

This simplicity is also the main advantage of IP . Because it does not do anything to the underlying physical media, the IP can be executed on any physical link that can host the packet, no matter what. For example, IP can be performed on simple serial links, Ethernet and Token Ring LANs, X. and using ATM (asychronous Transfer Mode. Asynchronous transfer Mode) for WAN, CDPD (Cellular digital Packet data, wireless cellular number packet) network, and very many other networks. Although there are very big differences between these network technologies, IP treats them equally. Except that they are able to forward the packet without any regard to it, no matter what. Such a mechanism implies very deep meaning. IP can be performed on any network that can host the packet, so the entire TCP/IP protocol family can.

Now let's look at how TCP uses such simple, non-connected services to provide reliable connection-oriented services. A packet of TCP is called a segment (segment), which is sent in an IP datagram. Therefore, it is impossible 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 primary IP service :
first of all . 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, it is really wrong, and the receiving side can 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 includes 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 each segment is finally delivered.

On the one hand, UDP provides an unreliable, non-connected service for program apes that write applications .

In fact, UDP only adds two functions to the underlying IP protocol.

First , it provides an optional checksum to detect the corruption of the data. Although IP also has a checksum, it only calculates 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 port.

Come back to the analogy with the phone/letter. We can treat the network address in the TCP connection as the telephone number of an office switchboard, and the number of ports as a station office is called a specific telephone extension number. Similarly, you can have a UDP network address in the apartment building, and port number as an apartment building in the lobby in your personal mailbox.

Linux Network Programming--there is no difference between a connection and a connection-oriented protocol