In article <d5olq0$lgi$1@inn.qnx.com>,
jeffadler.at.bigfoot.dot.com@nowhere.com says…
I have an application which uses a server on node 1 and display clients on
other nodes which access the server for nearly continuous updates of data.
These clients access data using QNX native send/receive/reply messaging.
I have recently added additional functionality which allows a remote client
to access the same data via TCP/IP.
I have created a server task on the remote box which emulates the node 1
server task as far as receiving messages. It then forwards these requests
via a TCP/IP stream socket to a receiving client on the node 1 server, which
in turn does a Send to the actual node 1 server task. The reply from the
node 1 server is routed back the other way.
This should sorta function like a virtual circuit over TCP/IP.
What I am finding is that the TCP/IP messaging is about 2.5 times slower
than QNX FLEET using virtual circuits between node 2 and node 1.
I am only opening up the connection once, and the sockets stay connected all
of the time, so no set-up / tear down is occuring.
My questions are:
- Is this the kind of speed difference that I should expect??
I think so. TCP provides you with a stream sent over packetized media
ethernet (or IP, it’s unreliable packet delivery protocol). When you
write data to TCP socket, TCP layer is free to wait some time for new
data in order to optimize sending of the stream by meaning of data
packets. To reduce overhead it is better to collect data into packet as
close to maximum packet size as possible. From other hand, if you are
not ready to provide some more data within a time frame, TCP layer must
send a small data packet. Receiving data TCP stack also may spend some
time to reconstruct the stream, especially if some packet took a
different route or was simple dropped.
- Are stream sockets a bad choice? Would dgram sockets result in a
significant improvement in speed?
Stream sockets are great choice and sometimes the only choice. Datagram
sockets would improve the speed for message passing model. But UDP does
not provide with reliable delivery of datagrams. Likely it is not what
you want, so you will have to do some extra work in your applications
(server and client) to provide fault tolerant message passing over UDP.
Improvement in speed greatly depends on your art to implement that. I
don’t think QNX4 supports Microsoft’s RDM (Reliably-Delivered Messages)
datagram protocol 
- Are there ways to improve the speed of a send / receive / reply model
over TCP/IP?
Sometimes there are options to slightly improve the speed of S/R/R model
over TCP. Unfortunately, I am not familiar with TCP/IP implementations
in QNX4, so I don’t know if they support any. In general, it is much
better to change model from S/R/R to stream. You said clients access the
server (i.e. server accepts connections) for nearly continuous stream of
data. It’s almost what you said starting this post
Cheers,
Eduard.
Thanks for any suggestion.
Jeff Adler
Automation Services, LLC
Denver, CO