🚀 go-pugleaf

Thanks.  Further questions below:

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:4606f07a$1@newsgroups.borland.com...
> Because the socket's internal receive buffer may not have enough room
> to hold all of the inbound data at one time.  Also, network latency
> can cause the socket to timeout internally and return whatever is
> currently in its buffer even if it isn't completely full yet.

So, is it possible to have one end send and have the send appear to be 
successful, but the other end not receive all of it or none of it?  Other 
than the expected length field (if implemented), can the receiver tell if 
the payload is fully received or not?

Does the WinSock layer provide data that is in sequence as and when its 
available?  eg.  the TCP/IP protocol makes sure data is received in the 
right order and uncorrupted, so if a payload takes say 100 packets, and if 
it receives packets 1-50, will it send it to the socket handler read layer, 
or does it wait for the whole 100 packets?


Does the number of routers / firewalls in the chain affect behaviour (other 
than latency)?

> The only way that can happen is if you have multiple threads writing
> to, or reading from, the same socket at the same time without
> serializing their access to the socket to prevent concurrent
> operations.

We were thinking of putting some more protocol headers and footers on the 
payload to make sure the data is fully received and uncorrupted.  The system 
in place is rather large and very busy, the number of packets per day that 
get corrupted is quite low, but the impact when it happens can be quite 
high.

I think the socket handling thread is written generically and is reading 
data in and offloading it to another level up for processing.  If there is 
something wrong with the reading process and its not detecting an error (eg. 
socket timeout), then the next level up will get the start of the next 
message and not realise it.

Thanks in advance.

Paul