The question is when does the receiver ack the data that I've sent ?
I'm trying to understand three way handshake ,and I thought that every message should be acked so I can continue sending the data
I find out nop
I discovered that there is receive window ,I said okay that’s it , the receiver will ack when the data reach the windows size , and of course I was wrong cause when looking at wireshark I discover that sometime before reaching it the receiver will acknowledge the msg, so I start wondering when does the ack happen ? and can this cause a problem?
Can this problem happen :
so suppose I’m the sender ME and my receive windows is 10 (just stupid example)
your receive windwows is 20 YOU
the msg size = 30bytes
ME so first I send 5 bytes → YOU don’t ack
ME :send 5bytes → YOU don’t ack (but your windows size changed so it only support 3 bytes )
u need to ack to tell me that
but in the same time I aleredy send 5byte wish is more than the 3bytes ,YOU : send a late ack telling me only 3bytes please
what will happens here ? And can this even happend ?
there is a specific time to send an ack so this will never happend ?
I’m learning so this can be a silly question be patient please , the 30bytes was : thank you so much for the help
Related
I read in my network textbook that in a TCP communication between host A and host B, if A sends an FIN to B, B will send an ACK back to A (suppose the Ack number of this packet is x) and enter the CLOSE-WAIT state. Then, B may still want to send some data to A. If not, B will right away sends back an FIN to A. No matter which case, the Ack number of this FIN sent by B should also be x.
My question is: When B is sending data in CLOSE-WAIT state, will it still receive ACK from A? If so, considering that the Ack number of the FIN to be sent by B should also be x, what will the SEQ of these ACK sent by A be? In other words, what will the Ack number of the packets sent by B in CLOASE-WAIT state be? Are all of them also x? If not, how could B know whether A has received the data or not?
I tried to search CLOSE-WAIT send data and something like this on Google but didn't find anything about this. And I also tried to search CLOSE-WAIT in RFC 793 but still didn't find anything about this question while browsing. It seems that I didn't use the correct keywords for retrieval.
I would be very grateful if you could attach the related contents in the RFC.
Hi I'm a newbie to networking, I can understand the differences between Go-Back-N and Selective Repeat protocol on transport layer.I'm confused with Selective Repeat, I know receiver might not be able to tell the incoming packet is a new packet or a retransmission when window size is set too large, but what I don't understand is why receiver need to know? the receiver can just send a ack packet back to sender and let the sender decide what to do next, then everything is fine, the protocol is still working properly.
why receiver need to know? the receiver can just send a ack packet
back to sender and let the sender decide what to do next
It's easy to forget, but the point of networking is not just to send acks and sequence numbers between computers. The receiver also needs to actually receive the data.
If the receiver can't tell whether a packet carries new information or a re-transmission, then it can't tell what information it received.
PSH is a way to send data via TCP. Besides that, I can find very little info on how to implement it properly.
Here is what interests me:
Let's say, server window is 8000 bytes, and I send 2 requests with 150 and 600 bytes. Do I get some sort of confirmation that the data has been received? Can I somehow trigger a confirmacion?
I've seen some ACK packets, which does not contain PSH but do contain some sort of payload data (Wireshark marks it as "TCP segment data"). Is this data passed on to user, and if it is, why do we need PSH flag?
TCP PSH generally doesn't 'work' at all. Berkely-derived TCP implementations completely ignore it.
Source: W.R. Stevens, TCP/IP Illustrated, vol I: 20.5 PUSH Flag.
#Arsen: Answering to the second part of your question "why do we need PSH flag?"
The PSH flag in the TCP header informs the receiving host that the data should be pushed up to the receiving application immediately.
We are using PSH flag to exchange Time Stamp value between two servers.
i am assuming , if we set push flag , packet wont wait in receive buffer , it will directly send to receiver.
The data doesn't sit waiting in the receive buffer anyhow.
TCP apps must go out of their way to have the TCP layer bulk up a few packets and deliver full data buffers.
In fact its somewhat frustrating to see applications allocate 64KB buffers to receive data and see them getting a gazillion 1480/1472 byte messages.
I'm not sure how to tell in TCP when the sender finished sending me the information.
For example if A needs to send 200 bytes to B, how will B know that A finished sending, and that the information is ready to be transferred to the application layer?
There's the FIN flag, but as far as I know it's only there to symbolizes that your going to close the connection.
Thanks.
TCP has no obligation to tell the receiver when the sender has finished sending data on the connection. It can't because it has no understanding of the higher level protocol data it's transporting.
However it will tell you if the connection closes (then you'll see a FIN, FIN-ACK) sequence in a network trace. From a programming perspective, assuming that you're using C the function recv will return 0 when the peer closes the connection.
You define a protocol such as first sending a 4 byte int in a specified byte order which indicates how many bytes will follow in the message body.
If you're on unix/linux, select and poll can signal you that the other end finished transfer (did a half/full close). read will also return with an error if you've read all the data and want to read from a closed connection.
If you do multiple transfers on one connection and want to signal the end of a "package" you have to build that into your protocol.
I'm building my own webserver based on a tutorial.
I have found a simple way to initiate a TCP connection and send one segment of http data (the webserver will run on a microcontroller, so it will be very small)
Anyway, the following is the sequence I need to go through:
receive SYN
send SYN,ACK
receive ACK (the connection is now established)
receive ACK with HTTP GET command
send ACK
send FIN,ACK with HTTP data (e.g 200 OK)
receive FIN,ACK <- I don't recieve this packet!
send ACK
Everything works fine until I send my acknowledgement and HTTP 200 OK message.
The client won't send an acknowledgement to those two packages and thus
no webpage is being displayed.
I've added a pcap file of the sequence how I recorded it with wireshark.
Pcap file: http://cl.ly/5f5/httpdump2.pcap
All sequence and acknowledgement numbers are correct, checksum are ok. Flags are also right.
I have no idea what is going wrong.
I think that step 6. should be just FIN, without ACK. What packet from the client are you ACKing at that place? Also I don't see why 4. should be an ACK instead of just a normal data packet - the client ACKed the connection at 3.
This diagram on TCP states might help.
WireShark says (of the FIN packet):
Broken TCP: The acknowledge field is
nonzero while the ACK flag is not set
I don't know for sure that's what's causing your problem, but if WireShark doesn't like that packet, maybe the client doesn't either. So, it should be FIN+ACK, or you should set the acknowledge field to 0.
If that doesn't solve it, you might also try sending the data first, then a separate FIN packet. It's valid to include data with the FIN, but it's more common to send the FIN by itself (as seen in the other pcap trace you posted earlier).
Also, you should probably be setting the PUSH flag in the packet with the 200 OK
Finally, I don't see any retransmission attempts for the FIN packet - is that because you stopped the capture right away?
The IP length field was consequently counting 8 bits too much. I made a mistake in my calculations. Everythings works like a charm now!