The SANE network protocol says that data is transfered as a series of blocks, each preceeded by the block size as a 4-byte integer. Observing, it appears that blocks are usually about 8KB (8188 in fact). However, a frontend program doesn't get a full block on each call. Nor does it get the maximum data length that it requests. Instead, for most calls, it seems to get 1488 bytes. I presume that is related to the Ethernet MTU of 1500 bytes, allowing for some overhead.
So, it seems that each sane_read() from a frontend gets the data in one Ethernet packet. Although the net backend make allowance for saving one byte between calls in some cases, it makes no attempt to combine several Ethernet packets into a single response. Am I understanding things correctly? If so, this seems to have two disadvantages. One, it reduceds efficiency by requiring more sane_read() calls by the frontend. (It doesn't change the network traffic.) Two, some (admittedly broken) frontends may depend on the ability to read a full scan line in one function call, and won't always succeed. It would make sense to me for the net backend to disengage the processing of network packets from the responses to sane_read() calls. It should collect multiple network packets up to a full block as declared by the leading 4 bytes. Doing this might also make it unnecessary to save a byte between calls for certain byte-order situations, as the entire block could be processed at once. Then the backend should fulfill sane_read() requests from the block buffer, reading another block whenever necessary, and only returning a short response at the end of file. Is anybody actively working on the net backend? Does this seem like a reasonable modification for somebody to undertake? Dave Close Dreamworks SKG, Animation Technology +1 818 695 6962 Glendale California 91201-3007 dcl...@anim.dreamworks.com http://www.dreamworks.com/
