Tcp fix #163
Draft
Tcp fix #163
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Lowered the frame size because if network card / router can't handle high frame, it will causes fragmentation, leading to packetloss or lost connection. It depends on the network card and router. A standard frame is 1518 bytes on the wire (as far as any capturing device is concerned). A tagged frame (single tag) is 1522 bytes on the wire. These take up 1538 bytes or 1542 bytes of transmission space on the wire. On most OS, it is usually set at 1542. As a safe measure. If one wants run on 90s network card, it should be set at 1518. I think this should be automated, not hardcoded.
Client(send) overrides host(receive) window size. It's one of the reasons why telnet chars and gopher files/links tend to drop. Packetloss/timeout.
The receive buffer is allocated per socket. TCP receive buffer holds TCP data that has not yet been processed (consumed via read/recv system calls) by the application.
…it remained unchanged.
Noticed slightly better responsive times while reducing timeouts.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
!!WIP!!
TLDR; reduced packet loss, reduced fragments, and reduced lost connection which may noticed a slightly increased speeds, and snappy response.
The window size is the amount of data that the receiving host is capable of accepting at any given time. The sender should limit the amount of data it sends based on the size of the window advertised by the receiver.
Receive window size isn't being recorded but instead we got a static client (sender) window size. Every time it communicate to the server, it negligence their window size. It say, "I don't care about your window size, mine is better." Basically it override host and thus it get corrupted part of the data. Telnet ANSI render gets messed up because it negligent the host data. This almost fixes it. I think once this get this panned out, there will be no issues with telnet client as well as losing connection to host when downloading files (I think there is a missing section that holds
Like for example..
Look at TCP.ZC LINE 1086
tcp_socket->receive_window = TCP_WINDOW_SIZE;Why are we getting client side window side when we are SUPPOSE to GET host window_size. Whatever we get from server gets override by client side static black magic number.
Furthermore, the biggest problem with this current code is that it tries to combine sender/receive information.
TCP.ZC LINE 67
TCPPacketAllocate {.....};This is a great example of getting confused. It combines send/receive. Those section needs rework.
Lastly, Endian...
Network bytes are BIG Endian. whatever it send out, it has to swap to B.E. It is coded in, that's good. However, I noticed that we're getting L.E. from the host which is odd. This could mess up telnet ANSI. I'm not sure. That'll be a different issue/pull request. This needs a study case after TCP send/receive is resolved.