Packet Order (TCP)

Question

Network administration

The script listens to pcap. Some messages, if they do not fit in one packet, are split into several packets. But sometimes it happens that the second part of the message (the second packet) arrives earlier than the first. I need to send packets to the application in the correct order (not necessarily whole messages, only the order matters), without significant timeout. Based on the package IDs, I can arrange them in the right order, but how can I be sure that at a particular moment in time I don’t have “missing” packages that will come next? Perhaps some headers (that this is only part of the message)? If so, which ones?
At the moment, the only solution I see is to make a timeout, but I don’t like it because of the magic-number timeout and still no guarantees.
PS
It is not possible to modify packets or the way they are transmitted.

Answer 1

Until FIN arrives, you can get another package from the other side.
Can you explain why you need node-pcap? What task do you want to do?

Answer 2

The script listens on a tcp socket == packets arrive in the correct order (the tcp stack has already done everything on its own)

Answer 3

TCP ensures that everything arrives in the correct order. All sent packets are numbered

Answer 4

If a script listens on a TCP socket using standard means (read/recv), then the TCP stack must ensure that the data is delivered in the correct order. I think that's what major meant .

By package ID, I can arrange them in the right order, but how can I be sure that at a particular moment in time I do not have "missing" packages that will come next? Perhaps some headers (that this is only part of the message)? If so, which ones?

It is not very clear what packages and identifiers we are talking about. TCP data stream integrity is ensured by the sequence number field of the TCP header (see www.ietf.org/rfc/rfc793.txt section 3.1) and the received data length (calculated from the total length field of the IP header, see tools.ietf.org/ html/rfc791#section-3.1 ). Namely, each transmitted byte of data is +1 to the sequence number. The initial sequence number is chosen randomly when the connection is established, i.e. when receiving a packet with the SYN flag. In the simplest case (without selective ack), each established connection must store the sequence number of the expected data and compare it with the sequence number received over the network; if they match, there is no missing data.

Answer 5

Packets, of course, may arrive in a different order. But here the kernel will give the data to your application always in the correct order.
Those. even if packets arrived with SEQ=1, and length 1000, as well as SEQ = 2501 and length 500, then the kernel realizing that something is missing (1500 bytes are missing in the middle - the second SEQ, i.e. byte number, 2501 , and so far we have had bytes up to 1000 inclusive), will not send the second packet to the application layer. And over the network, the kernel will send ACK 1000 that it received the first packet, hinting that there are no more.
As soon as a packet arrives with SEQ 1001 and some length, it will be given to the kernel. A packet with SEQ=2501, although the kernel already has it for a long time, will not be given to your application until all 1500 bytes with numbers 1001 to 2500 inclusive reach, no matter how many packets they are scattered over (at least 1500 packets one at a time). byte). If a timeout occurs during the transmission of these intermediate packets, then your application will never see the packet with SEQ=2501, although the kernel of the receiving system had it.
(I want to draw attention to the fact that the packets are not numbered. The bytes are numbered. The SEQ field in the packet is the serial number of the first byte of this packet. One subtlety: the numbering starts not from 0 and not from 1, but from a random number, which is determined by the sender during installation connections - in a packet with the SYN flag. The example above should be understood so that the SYN was with SEQ=1).
That is, you can not worry about the fact that intermediate packets will not reach you in the case of TCP. If you write bytes to a socket in a certain order on one end, you on the other end will either receive them in exactly the same order, or not at all.