alec1o
commented
4 weeks ago :sob: It's not possible to read package header, it mean we must implement message framing in application layer like now.
https://stackoverflow.com/questions/73237486/creating-tcp-connection-and-getting-the-header https://stackoverflow.com/questions/11034870/how-do-you-get-raw-tcp-packet-in-c
:+1: https://stackoverflow.com/questions/73237486/creating-tcp-connection-and-getting-the-header
Protocols like http detect the framing of your data through the stream, and create the framing at the application level, Netly's function is to provide the socket and optionally contains the framing at the application level since version 3, much more I think netly it should be smart enough to create frames through the headers received by the sender. And that: Relying on TCP headers to create a "frame" rather than creating a frame based on the data received.
Advantage of application-level framing?
Advantage of framing at socket level?
Resilient (if you can put framing at the socket level, it means all applications communicate without dependency and overhead)
No overhead (This is by sending both and receiving data the libraries do not need to send extra data in the message body to handle framing at the application level.
What am I trying to say with framing?
TCP has a very low data limit and if you want to send 1 megabyte you cannot send it linearly, that is, you need to divide this data and send it in small pieces and the framing function both at the application level and at the socket level is to detect and accumulate the data until it reaches 1 megabytes and only then release it to the receiving target. in case of download, it can be a file on the disk to write to the buffer each time it receives a fragment of data. Netly by default will use the memory as a buffer, this works well if the data to be received is small, i.e. less than ~10 megabytes, and in case of receiving Gigabytes, Netly will need to use the gigabytes in RAM, and that's where the danger lies. and problem. Netly currently has framing at the application level and has a limit of 8 megabytes that it allows to receive and this can be customized up to as much GB, TB, etc. as you want. The next update to fix this should be to allow netly to write the buffer to disk in a temporary folder and then pass the file path instead of data in a parameter. This can be customized, for example from 10MB. In any case, this is a danger that resides in the framing of any layer, But being realistic, most users don't even use 1MB, they use it to browse messages and small data and will rarely send large files. In any case, netly being able to deal with framing at the socket level brings compatibility without overhead and with data resilience.