Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
While observing network traffic in wireshark, i see that wireshark reassembles packets like:
[Reassembled TCP Segments (4233 bytes): #1279(2133), #1278(2100)]
Packet #1278: blahblah, Seq: 1538, Ack:3074, Len: 2133
Packet #1279: blahblah, Seq: 2998, Ack:3074, Len: 2100
(lengths are fictional values)
Im looking to reassemble tcp packets that i receive through sharppcap
Does wireshark use Ack to know what segments belong to each other?
What is the Seq value refer to?
If not, how does it reassemble them?
SEQ values are counted in bytes, so if you receive a 100 byte segment with SEQ == 5, you know the next segment in the sequence will have a SEQ == 105.
The ACK indicates the next SEQ value that the sender expects to see from its peer. So the only reason you're seeing the same ACK value in multiple packets is because only one side is transmitting. By keeping the ACK the same, With each transmission, the host is basically saying it hasn't received anything new.
The sequence number identifies the first byte in the segment. As part of connection establishment each peer picks a random sequence number for the first byte that it will send. Thereafter, the next sequence number is the previous sequence number plus the number of bytes in the previous segment.
I don't understand your question about whether Wireshark uses Ack to reassemble segments.
I might be wrong,
It is not up to TCP to reassemble the PDU..TCP's job is to make sure the tcp segments arrive in order(seq, ack), it does not care about the upper layer protocols..
e.g. a long HTTP response(suppose you are downloading some large file), TCP does not know (neither does it care) where the end of the request is, because that's HTTP's job
Related
In a situation where both client and server sets their respective sequence number to 0, I read that the following is true:
C-->S: SYN=1, SEQ=0 (No data bytes)
C<--S: SYN=1, SEQ=0, ACK=1 (No data bytes)
C-->S: SEQ=1, ACK=1 (Data bytes optional)
In the third part, I understand the server is expecting the next sequence number to be 1, but aren't sequence numbers supposed to be set to initial_seq_num + sent_data_bytes_num? Since there was no data bytes sent in the first part of the handshake shouldn't the seq # be 0?
Is this just an exception during the handshake or are segments sent to with no data bytes supposed to increment the sequence number by 1 if they can be sent at all?
(There is a similar Q & A but the answer doesn't explain if this is an exception during the handshake phase OR if this happens after a TCP connection has been establish. I'm not even sure if a segment with no data bytes can even be sent. I'm assuming you can't)
ADDED It seems TCP keep-alive packets have no payload either. RFC 1122 says in these packets, SEG.SEQ = SND.NXT-1, and because this sequence number will be an already ACKed number, and a duplicate ACK will be sent, so as to keep the sequence number of the server the same.
Otherwise, I couldn't find any indications of what needs to be done when the sequence number is correct but there is no payload. I might be wrong since I only briefly scanned the document, but there is also no statement of rules of sequence numbering during the handshake except for examples.
In RFC 1122, it says
Unfortunately, some misbehaved TCP implementations fail to respond to a segment with SEG.SEQ = SND.NXT-1 unless the segment contains data.
So I'm assuming it depends on each implementation, but if there is any statement of a) the sequence numbering during handshake, and b) how to behave when the sequence # is correct but there is no payload, I would really appreciate it if someone could point me to that part.
Thanks!
The first ACK (that occurs as part of Handshake) acknowledges the reception of SYN from the other end. The SYN segment does not carry any data. But to allow the provision for acknowledging the reception of SYN, the first ACK is incremented though no payload is present.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
According to TCP, sequence number is used to refer to bytes instead of being a counter. The sequence number is 32-bit integer (~4.2 GB).
If I am sending file directly using TCP, I can't exceed this number.
This was okay with old file-systems but now we have files exceeding this size.
I believe Application layer protocols has been modified to bypass this limit, can any provide an example for this or at least list the used techniques?
For reference, the question was based on the following problem
Textbook : Computer Networking: A Top-Down Approach by James F. Kurose , Keith W. Ross.
P26. Consider transferring an enormous file of L bytes from Host A to Host B.
Assume an MSS of 536 bytes.
a. What is the maximum value of L such that TCP sequence numbers are not
exhausted? Recall that the TCP sequence number field has 4 bytes.
If I am sending file directly using TCP, I can't exceed this number.
Yes you can. You are mistaken. It wraps around.
P26. Consider transferring an enormous file of L bytes from Host A to Host B. Assume an MSS of 536 bytes. a. What is the maximum value of L such that TCP sequence numbers are not exhausted? Recall that the TCP sequence number field has 4 bytes.
'Sequence numbers are not exhausted' is a constraint for the purposes of this question, but the authors aren't necessarily thereby claiming that such a limit applies to any TCP transmission. If they are, they're manifestly wrong. Consider that the initial sequence number is chosen randomly, and therefore can be 2^32-1. Does that imply a limit on that connection of one byte? Of course it doesn't.
I also note that the MSS of 536 bytes is entirely irrelevant to the question. Possibly this is just a substandard text.
EDIT I've now located this source. You didn't misunderstand it. There is nothing in the book about TCP sequence number exhaustion except for this stupid question. Nothing about it wrapping around either, which is a curious omission. The MSS is used in the second part of the book problem, not quoted here.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Can someone please explain me what is overhead, payload, header and packet. As far as I know a packet is the whole data that is to be transmitted. This packet consists of the actual data which I think is the payload and the source/destination information of the packet is in the header. So a packet consists of header and payload. So what is this overhead? Is overhead a part of the header? I got this from the internet "Packet overheard includes all the extra bytes of information that are stored in the packet header".
The header already contains source/destination info. What are the extra bytes of information that this packet overhead has? I'm confused.
The packet like you said, have the "payload" which is the data itself it needs to transfer (usually the user's data), the "header" contains various things depends on the protocol you are using, for example UDP contains just simple things in the header like Destination and Source IP/PORT, TCP on the other end contains more things like the sequence number of the packet to ensure ordered delivery, a lot of flags to ensure the packet actually received in it's destination and checksum of the data to make sure it didn't get corrupted and received correctly in its detination.
Now, the "overhead" part is actually the additional data that you need in order to send your payload. In the cases I talked about above it's the header part, because you need to add it to every payload that you want to send over the internet. TCP has bigger overhead than UDP because it needs to add more data to your payload, but you are guaranteed that your data will be received in it's destination, in the order you sent it and not corrupted. UDP does not have this features so it can't guarantee that.
Sometimes you will read/hear discussions on what protocol to use according to the data you want to send. For example, let's say you have a game, and you want to update the player's position everytime he moves, the payload it self will contain this:
int playerID;
float posX;
float posY;
The payload's size is 12 byte, and let's say we send it using TCP, now the whole packet will look like this:
-------------
TCP_HEADER
-------------
int playedID;
float posX;
float posY;
Now the whole packet's size is payload + TCP_HEADER which is 12 bytes + (32 bytes to 72 bytes), you now have 32 to 72 bytes overhead for your data. You can read about TCP's header here. Notice that the overhead is even bigger than the data itself!
Now you need to decide if it is the protocol you want to use for your game, if you don't need the features TCP offers you better of using UDP because it have smaller overhead and therefore less data to be sent.
You are correct that a packet generally consists of a header and then the payload. The overhead of a packet type is the amount of wasted bandwidth that is required to transmit the payload. The packet header is extra information put on top of the payload of the packet to ensure it gets to its destination.
The overhead is variable because you can choose a different type of packet (Or packet protocol) to transmit the data. Different packet protocols give you different features. The two key type of packet protocols that exist today are TCP and UDP.
One can say UDP has a lower overhead than TCP because its packets have a smaller header and therefore take less bandwidth to send the payload (The data).
The reasons for this are a deep subject but suffice to say that TCP provides many very useful features that UDP does not, such as ensured delivery of the packets and corruption detection. Both are very useful protocols and are chosen based on what features an application needs (Speed or reliability).
This question already has answers here:
How do I get amount of queued data for UDP socket?
(2 answers)
Closed 4 years ago.
Which one does ioctl of FIONREAD return, the next packet's length, or the length of all data in the buffer?
Suppose there is a UDP server that receives 2 packets from a client 1 and another 2 packets from client 2 after client 1's packet.
Then, what is the value of ioctl of FIONREAD,
and what does readfrom return in that case?
Client 1 : v two packets
++UDP Server got 4 packets <- FIONREAD?
Client 2 : ^ two packets
FIONREAD? (server)
length of client 1's first packet
length of client 1's two packets
length of client 1's two packets + client 2's two packets
length of client 1's first packet + client 2's first packet
other
man udp (7) states:
FIONREAD (SIOCINQ)
Gets a pointer to an integer as argument. Returns the size of
the next pending datagram in the integer in bytes, or 0 when no
datagram is pending. Warning: Using FIONREAD, it is impossible
to distinguish the case where no datagram is pending from the
case where the next pending datagram contains zero bytes of
data. It is safer to use select(2), poll(2), or epoll(7) to
distinguish these cases.
So, the answer to your question is: FIONREAD returns the size of the next (first) pending datagram.
It is platform-dependent.
On some platforms, FIONREAD on a UDP socket returns the size of the first datagram.
On others it returns the total number of bytes that can be read without blocking, which is the total number of bytes presently in the socket receive buffer.
See here for further information.
The return value of recvfrom() is the actual number of bytes transferred.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Why does TCP wait for three duplicate ACK before fast retransmit?
RFC 2001 says
Since TCP does not know whether a duplicate ACK is caused by a lost
segment or just a reordering of segments, it waits for a small number
of duplicate ACKs to be received. It is assumed that if there is
just a reordering of the segments, there will be only one or two
duplicate ACKs before the reordered segment is processed, which will
then generate a new ACK. If three or more duplicate ACKs are
received in a row, it is a strong indication that a segment has been
lost. TCP then performs a retransmission of what appears to be the
missing segment, without waiting for a retransmission timer to
expire.
The reasoning for not doing the retransmit until the third duplicate seems to be that until that point it's more likely to just be out-of-order delivery and the retransmit isn't really needed.