read larger data streams over sockets - broken?

[Phil Davis]

Is anyone else having problems with moving multi-MB data streams across 
sockets in LC 8?

I support a LAN-based system that relies on sockets to move data between 
server and clients. The server's response to a single client request 
will often consist of several hundred KB to several MB of data. Until LC 
8 the successful approach has been:

- client sends request to server

- server returns data to client

- client reads the returned data:

    read from socket tMySocket for 1 line -- contains the length of the
    data that follows
    put it into tDataLength
    repeat while length(tData) < tDataLength
         read from socket tMySocket for tDataLength
         wait 1 millisecond with messages
         put it after tData
    end repeat

This approach no longer works in LC 8. There are 2 new issues:
     - large time delays
     - wrong final data size

Here are some actual results from a client that was trying to receive 
151k of data - not that big!

    tDataLength = 151954

    read #1 got 0 chars in 15.25521 secs
    read #2 got 131761 chars in 15.001723 secs
    read #3 got 131761 chars in 0.001813 secs
    actual received data length = 263522
    total elapsed time = 30.259262 secs

I changed the client code to read 'until EOF' and got similar outcomes:

    tDataLength = 151954

    read until EOF #1 got 0 chars in 15.254117 secs
    read until EOF #2 got 131761 chars in 15.004341 secs
    read until EOF #3 got 131761 chars in 0.001733 secs
    actual received data length = 263522
    total elapsed time = 30.260464 secs

Either 'read' structure works fine as long as the data length doesn't 
exceed roughly 128k (that's the max in my world at least - YMMV). I'm 
not sure if the 128k size constraint is coming from LC or from my 
network (a standard gigabit-Ethernet LAN with router, switches, 
computers) or from some other source.

I know this is a bug and plan to file a bug report, but I wanted to see 
if anyone else has experienced something similar.

Thanks -
Phil Davis

-- 
Phil Davis