Just a couple of comments:
TCP/IP ensures that data gets from one node to another without errors; it
does not ensure that the data is saved on the receiving end in non-volatile
storage. So, to ensure that data isn’t lost, you should layer an
application-level acknowledgment on top of TCP/IP. That is, the sender
should queue up a transaction, e.g. to disk, then send it via TCP/IP. The
receiver should, upon receipt, save the transaction somewhere safe, then
send an ack to the sender. At this point the sender may delete the
transaction locally, and send the next. The idea is that the transaction
should exist on safe storage on at least one node at all times.
A “gotcha” with TCP/IP is to assume that transactions are sent atomically;
that is, if you send an entire buffer of data with one system call, you
assume the receiver will also receive the entire buffer with one system
call. This might work a high percentage of the time, but it is not
guaranteed, and will eventually fail. The reason is that the sent buffer may
get fragmented, and the receiver may need to make many system calls to
receive the entire structure.
The upshot is that TCP/IP for secure data transfer should be treated as a
serial data stream, with the need to assemble frames from small pieces upon
receipt, check sequence numbers for duplicates, do retries, and the like.
Of course, if you don’t mind losing data once in a while due to network or
node failures, then all of this is unneccessary.
“Doug Rixmann” <email@example.com> wrote in message
I’m looking for any advice or comments on how to proceed with implementing
networking architecture using TCP/IP communications. Our application (on
QNX4.25) is very network intensive and we have been having problems with
current implementation using Send/Recv/Reply. We are looking to utilize
TCP/IP protocol to ensure delivery and to have more notification when
something goes wrong. We are also looking into this to be able to support
third-party devices that may exist on another OS (Window, Linux, other).
Possibly thoughts on Publish/Subscribe, Broadcast, or any other experience
that you wouldn’t mind sharing.