Server can't read as much data as he may need
Bug #555873 reported by
Paco
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
El Jardin |
Won't Fix
|
Low
|
Paco |
Bug Description
Server side of jardin accepts a new connection, then reads as much as JARDIN_
New method must be provided for user/caller to read as much as he needs.
Changed in eljardin: | |
importance: | Undecided → Critical |
assignee: | nobody → Paco (manuel-arguelles) |
To post a comment you must log in.
Server is not really reading in the first iteration as much as JARDIN_ DEFAULT_ RECV_BUFFER_ SIZE. The buffer may get filled only partially, and the user-provided callback gets called; then more bytes arrive, and user-provided callback gets called again. Note that this issue is only applicable to STREAM connections (TCP if INET), as with DGRAM the whole datagram arrives as a whole and user-provided callback is only called once.
If I understand the issue properly, you suggest to enable some way to wait & read more bytes inside the user-enabled callback right? If so, this is not really recommended, as you would be blocking the whole thread of execution while waiting for more data to come.
If waiting for a loong stream of bytes to arrive, it should be a task of the programmer to decide what to do while the whole stream didn't arrive. For example, if the stream of bytes is a 8GB DVD image arriving through TCP, the user-defined callback should never block & wait for the arrival of the whole chunk. In this case, the user-provided callback should receive each stream chunk in the recv buffer, and append the received bytes to a temporary file somewhere, until the whole stream of bytes arrives and the user-defined callback can properly generate the received file with all its contents.
If thinking in smaller streams of bytes, the temporary store with the already received stream chunks may be stored in heap memory instead of disk.
My 2 cents.