🚀 go-pugleaf

"Paul at NCF" <notplmacca@clara.co.uk> wrote in message
news:46079e5f$1@newsgroups.borland.com...

> 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?

TCP/IP guarantees data delivery and integrity.  The only time where
that would not be the case is when a connection/network error has
occured.

The send() function returns whether the socket accepted the specified
data into its internal sending buffer.  It does not reurn whether the
data has actually been sent over the wire successfully.  There is
nothing in the socket API to get that kind of information.  It is
possible for the sender to see the data being accepted successfully,
but then a connection/network error occurs before the data actually
reaches the other party.  In that scenerio, both parties will receive
notifications of the error and the connection will be invalidated.

> Other than the expected length field (if implemented), can the
receiver
> tell if the payload is fully received or not?

TCP is an arbitrary byte stream.  It has no concept about the contents
of the payload.  All it cares about is that the data being passed to
it is delivered as-is.  The higher-level protocol implemented on top
of TCP at the application layer dictates what the data actually
represents.  So the application is responsible for checking the data
it receives.  There is only 2 ways to know where one payload ends and
the next begins - either the data is prefixed with the data's length,
or the data ends with a unique terminator that does not appear
anywhere else in the data.  In the latter case, the application has to
actually process the contents of the data in order to determine that.

> 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

That is what TCP does, yes.  But it does not control the timing of the
packets.

> 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?

I already answered that in my earlier reply.  It has to do with the
socket's internal buffering at the time.  It is entirely possible that
the application will be given 1-50 before 51-100 have arrived yet.
Also, depending on the application's own buffering, it is possible for
it to receive 1-25 1/2, then 25 1/2-37 3/4, etc.  The issue handling
split and concatenated data blocks has been discussed many many times
before in these groups.

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

Only if they drop packets.

> We were thinking of putting some more protocol headers and footers
> on the payload to make sure the data is fully received and
uncorrupted.

That is perfectly fine.

> 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.

The fact that you are getting any corruption at all suggests the
possibility that you may not be reading/writing the data in your code
properly to begin with.

> I think the socket handling thread is written generically and is
reading
> data in and offloading it to another level up for processing.

That is also fine - as long as concurrent reading from that socket
across multiple threads is handled in a thread-safe manner.  If that
is the only thread that ever reads from the socket, though, then there
is nothing to worry about on that part.  Then again, the sender could
be the culprit of your overlapping packets instead.


Gambit