Jim says
Good.
See for example https://en.wikipedia.org/wiki/Transmission_Control_Protocol for a discussion of the 3-way handshake
and the FIN packet(s) - one side may start to tear down the connection, thinking its done, but that doesn't finish
until both sides do. Not sure exactly what's what here without more digging.
Nate's Work
- Analyzed an interaction with my protocol blackjack game using the loopback capture filter that captures internal network traffic
- Below is a screenshot of every packet in the interaction with one of the larger server - client packets highlighted
- All the packets were sent on the tcp protocol to the ip address of 127.0.0.1
- The server is listening on and sending from port 12345 while the client is listening on/sending from port 63664
- Essentially every packet with 56 bits of information and just an ACK is a built in confirmation of connection or receipt of data
- Every packet that has a [PSH] in addition to an [ACK] has a piece of data I coded embedded in it, beyond just the acknowledgement, PSH seems to indicate that the contained data needs to be sent on to the requesting piece of software utilizing the protocol
- I'm thinking that the first couple requests are just establishing the connection and then the first FIN request from the server is when it's spawning a separate thread and closing the connection to listen for new clients? Not quite sure because FIN represents the end of connection and clearly the connection isn't ending
- In TCP every packet received is acknowledged and I also have a confirmed/unconfirmed call and response set up so every interaction is splayed out between 4 packages. ie: server sends some data, client acknowledges it, client sends acknowledgement or response data, server acknowledges receipt of acknowledgement, server sends some new data
- The last interaction is a FIN sent from the client, ACKnowledged by the server, which ends the interaction and seems to support my earlier hypothesis that the server is already ready to close
- Useful links in figuring out what FIN, ACK, SYN mean:
- https://osqa-ask.wireshark.org/questions/50641/fin-ack-sending-without-getting-prior-fin-from-counter-part
- http://packetlife.net/blog/2010/jun/7/understanding-tcp-sequence-acknowledgment-numbers/