> Or, is your 3000 replying, yes, I got message #123,456,
> here's your checksum
> (or whatever) to confirm that I really, truly got it? If the
> latter, it
> sounds like a poorly defined process, since TCP/IP pretty
> much already does all of that for you,

TCP doesn't do *any* of that for you.

What TCP promises is that, *at the protocol level*,
 1) a stream of bytes accepted at one end of a connection for transfer
will be delivered complete and in sequence to the other end, or
 2) the error will be reported to the protocol, resulting (usually) in
a connection reset

TCP knows *nothing* about application-level return-receipt, integrity,
or other concerns. And there's no such thing as a TCP "message".

Specifically, a successful send()/IPCSEND()/whateversend() call means
that at least some of the data provided has been accepted by the
protocol for transport. And that's all it means. In particular, it
does NOT mean that
 1) Any of the data has been--or ever will be--received at the other
end
 2) Any of the data has been--or ever will be--placed "on the wire" at
the sender's end

Proper management of connection termination via the "linger" option
and socket shutdown and closure functions can maximize the chance that
the data at least gets to the hardware on the sending machine, but
nothing is available at the socket level to check progress, receipt,
or integrity; those must be handled by the application.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *