Zeal-Operating-System / ZealOS

The Zeal Operating System is a modernized fork of the 64-bit Temple Operating System, TempleOS.
https://zealos.net
The Unlicense
1.47k stars 68 forks source link

Tcp fix #163

Open Z8Griz opened 1 month ago

Z8Griz commented 1 month ago

!!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.