QNX4: Lost TCP packets

Hello all-

I have written a program that sends screen updates from my QNX4 application
to a remote client over TCP/IP. The goal is to replace my applications
console output commands (console_write, etc.) with TCP writes to another
machine, which in turn receives the commands and then does the console
writes itself.

Essentially, I am moving the screen off of the local machine to a remote
machine over TCP.

There is no program acknowledgement between the host and the remote; i.e the
remote client doesn’t specifically acknowledge receipt of the packets from
the host. The host just blindly sends control command packets, much like a
computer talking to a dumb terminal.

The program seems to work just fine if the “remote” program is running on
the local machine and connecting to “localhost”.

When I run the remote “client” program on a remote machine (256KB TCP/IP
connection), I seem to occasionally lose blocks of TCP packets. There
doesn’t seem to be any error returned on the host (that I can tell).

Each transmit packet has a header with an incrementing “tnx_id”. I have the
client program outputting the info from the packets. After a large “send”,
a few more packets arrive OK, and then a tnx gap:

client msg: tnx_id=1, size=17446, h_cmd= 201, cmd=20505
client msg: tnx_id=2, size= 20, h_cmd= 200, cmd=10009
client msg: tnx_id=3, size= 20, h_cmd= 200, cmd=10008
client msg: tnx_id=4, size= 20, h_cmd= 200, cmd=10011
client msg: tnx_id=5, size= 39, h_cmd= 203, cmd=24872
client msg: tnx_id=6, size= 20, h_cmd= 200, cmd=10011
client msg: tnx_id=7, size= 20, h_cmd= 200, cmd=10011
client msg: tnx_id=8, size= 20, h_cmd= 200, cmd=10006
client msg: tnx_id=9, size= 3860, h_cmd= 200, cmd=10002
client msg: tnx_id=10, size= 20, h_cmd= 200, cmd=10006
client msg: tnx_id=11, size= 20, h_cmd= 200, cmd=10008
client msg: tnx_id=12, size= 20, h_cmd= 200, cmd=10006
client msg: tnx_id=13, size= 78, h_cmd= 200, cmd=10002
client msg: tnx_id=14, size= 50, h_cmd= 200, cmd=10002
client msg: tnx_id=15, size= 20, h_cmd= 200, cmd=10008
client msg: tnx_id=16, size= 20, h_cmd= 200, cmd=10006
client msg: tnx_id=17, size= 20, h_cmd= 200, cmd=10006
client msg: tnx_id=18, size= 20, h_cmd= 200, cmd=10003
client msg: tnx_id=19, size= 6900, h_cmd= 200, cmd=10002
client msg: tnx_id=20, size= 20, h_cmd= 200, cmd=10006
client msg: tnx_id=21, size= 39, h_cmd= 203, cmd=24872
client msg: tnx_id=22, size= 20, h_cmd= 200, cmd=10008
client msg: tnx_id=200, size= 30, h_cmd= 200, cmd=10002
*** tnx id sequence error
client msg: tnx_id=201, size= 30, h_cmd= 200, cmd=10002
client msg: tnx_id=202, size= 28, h_cmd= 200, cmd=10002
client msg: tnx_id=203, size= 30, h_cmd= 200, cmd=10002

Does anyone have any ideas? Any help would be much appreciated.

Thanks,

Jeff.

In general sending data via TCP/IP or UDP over a local network is very
reliable. No such reliability should be assumed over the Internet.
TCP/IP will guarentee the integrity of a data packet, if it arrives.
It doesn’t guarentee the arrival of the packet at all. Furthermore,
there is no error on either side.

I was very surprised when I first learned of this, years ago. When
you use TCP/IP you are expected to provide a higher level protocol
that deals with ACK/NAK and timeout issues.

maschoen wrote:

In general sending data via TCP/IP or UDP

UDP is completely un-reliable.

over a local network is very

reliable. No such reliability should be assumed over the Internet.
TCP/IP will guarentee the integrity of a data packet, if it arrives.
It doesn’t guarentee the arrival of the packet at all.

TCP/IP does garantee the arival of packets as long as e.g. retransmit
counters are exhausted.

Furthermore,
there is no error on either side.

I was very surprised when I first learned of this, years ago. When
you use TCP/IP you are expected to provide a higher level protocol
that deals with ACK/NAK and timeout issues.

OK, then why am I loosing packets?? I am using TCP sockets. (QNX4 TCP/IP
5.0C)



“Armin Steinhoff” <a-steinhoff@web.de> wrote in message
news:eakole$5b9$1@inn.qnx.com

maschoen wrote:
In general sending data via TCP/IP or UDP

UDP is completely un-reliable.

over a local network is very
reliable. No such reliability should be assumed over the Internet.
TCP/IP will guarentee the integrity of a data packet, if it arrives. It
doesn’t guarentee the arrival of the packet at all.

TCP/IP does garantee the arival of packets as long as e.g. retransmit
counters are exhausted.

Furthermore,
there is no error on either side. I was very surprised when I first
learned of this, years ago. When
you use TCP/IP you are expected to provide a higher level protocol
that deals with ACK/NAK and timeout issues.

Just a thought -

I have seen the situation where a send() is done with a large amount of
data, and the corresponding recv() assumes that the entire send() buffer was
captured with one recv(). Since TCP is a stream protocol, this is not
guaranteed. Instead, the large send() might get broken up into several
chunks, and the first recv() will only get part of it; this can happen
because not all of the send() has shown up, even though the recv() has
sufficient buffer space to take in the entire send(). The next recv() might
get the next part, and so on, with the recv() buffers no longer
corresponding to an application frame. This might unsync your sender and
receiver for a while, until the beginning of an application frame once again
syncs up with the recv() buffer; in the interim, application frames get
lost.

“Jeffrey Adler” jeffadler.at.bigfoot.dot.com@127.0.0.1 wrote in message
news:eagav6$5u6$1@inn.qnx.com

Hello all-

I have written a program that sends screen updates from my QNX4
application to a remote client over TCP/IP. The goal is to replace my
applications console output commands (console_write, etc.) with TCP writes
to another machine, which in turn receives the commands and then does the
console writes itself.

Essentially, I am moving the screen off of the local machine to a remote
machine over TCP.

There is no program acknowledgement between the host and the remote; i.e
the remote client doesn’t specifically acknowledge receipt of the packets
from the host. The host just blindly sends control command packets, much
like a computer talking to a dumb terminal.

The program seems to work just fine if the “remote” program is running on
the local machine and connecting to “localhost”.

When I run the remote “client” program on a remote machine (256KB TCP/IP
connection), I seem to occasionally lose blocks of TCP packets. There
doesn’t seem to be any error returned on the host (that I can tell).

Each transmit packet has a header with an incrementing “tnx_id”. I have
the client program outputting the info from the packets. After a large
“send”, a few more packets arrive OK, and then a tnx gap:

client msg: tnx_id=1, size=17446, h_cmd= 201, cmd=20505
client msg: tnx_id=2, size= 20, h_cmd= 200, cmd=10009
client msg: tnx_id=3, size= 20, h_cmd= 200, cmd=10008
client msg: tnx_id=4, size= 20, h_cmd= 200, cmd=10011
client msg: tnx_id=5, size= 39, h_cmd= 203, cmd=24872
client msg: tnx_id=6, size= 20, h_cmd= 200, cmd=10011
client msg: tnx_id=7, size= 20, h_cmd= 200, cmd=10011
client msg: tnx_id=8, size= 20, h_cmd= 200, cmd=10006
client msg: tnx_id=9, size= 3860, h_cmd= 200, cmd=10002
client msg: tnx_id=10, size= 20, h_cmd= 200, cmd=10006
client msg: tnx_id=11, size= 20, h_cmd= 200, cmd=10008
client msg: tnx_id=12, size= 20, h_cmd= 200, cmd=10006
client msg: tnx_id=13, size= 78, h_cmd= 200, cmd=10002
client msg: tnx_id=14, size= 50, h_cmd= 200, cmd=10002
client msg: tnx_id=15, size= 20, h_cmd= 200, cmd=10008
client msg: tnx_id=16, size= 20, h_cmd= 200, cmd=10006
client msg: tnx_id=17, size= 20, h_cmd= 200, cmd=10006
client msg: tnx_id=18, size= 20, h_cmd= 200, cmd=10003
client msg: tnx_id=19, size= 6900, h_cmd= 200, cmd=10002
client msg: tnx_id=20, size= 20, h_cmd= 200, cmd=10006
client msg: tnx_id=21, size= 39, h_cmd= 203, cmd=24872
client msg: tnx_id=22, size= 20, h_cmd= 200, cmd=10008
client msg: tnx_id=200, size= 30, h_cmd= 200, cmd=10002
*** tnx id sequence error
client msg: tnx_id=201, size= 30, h_cmd= 200, cmd=10002
client msg: tnx_id=202, size= 28, h_cmd= 200, cmd=10002
client msg: tnx_id=203, size= 30, h_cmd= 200, cmd=10002

Does anyone have any ideas? Any help would be much appreciated.

Thanks,

Jeff.

Thanks, but that’s not today’s problem.

I too have had the problem you speak of, and expect it.

When larger amounts of data (sometimes only 100+ bytes) are received, the
“read()” can complete with less than the expected amount. Additional reads
are often required to get the whole packet.

Thanks anyway,

Jeff.

“Kevin Miller” <kevin.miller@transcore.com> wrote in message
news:eanp90$6v9$1@inn.qnx.com

Just a thought -

I have seen the situation where a send() is done with a large amount of
data, and the corresponding recv() assumes that the entire send() buffer
was captured with one recv(). Since TCP is a stream protocol, this is not
guaranteed. Instead, the large send() might get broken up into several
chunks, and the first recv() will only get part of it; this can happen
because not all of the send() has shown up, even though the recv() has
sufficient buffer space to take in the entire send(). The next recv()
might get the next part, and so on, with the recv() buffers no longer
corresponding to an application frame. This might unsync your sender and
receiver for a while, until the beginning of an application frame once
again syncs up with the recv() buffer; in the interim, application frames
get lost.

“Jeffrey Adler” jeffadler.at.bigfoot.dot.com@127.0.0.1 wrote in message
news:eagav6$5u6$> 1@inn.qnx.com> …
Hello all-

I have written a program that sends screen updates from my QNX4
application to a remote client over TCP/IP. The goal is to replace my
applications console output commands (console_write, etc.) with TCP
writes to another machine, which in turn receives the commands and then
does the console writes itself.

Essentially, I am moving the screen off of the local machine to a remote
machine over TCP.

There is no program acknowledgement between the host and the remote; i.e
the remote client doesn’t specifically acknowledge receipt of the packets
from the host. The host just blindly sends control command packets, much
like a computer talking to a dumb terminal.

The program seems to work just fine if the “remote” program is running on
the local machine and connecting to “localhost”.

When I run the remote “client” program on a remote machine (256KB TCP/IP
connection), I seem to occasionally lose blocks of TCP packets. There
doesn’t seem to be any error returned on the host (that I can tell).

Each transmit packet has a header with an incrementing “tnx_id”. I have
the client program outputting the info from the packets. After a large
“send”, a few more packets arrive OK, and then a tnx gap:

client msg: tnx_id=1, size=17446, h_cmd= 201, cmd=20505
client msg: tnx_id=2, size= 20, h_cmd= 200, cmd=10009
client msg: tnx_id=3, size= 20, h_cmd= 200, cmd=10008
client msg: tnx_id=4, size= 20, h_cmd= 200, cmd=10011
client msg: tnx_id=5, size= 39, h_cmd= 203, cmd=24872
client msg: tnx_id=6, size= 20, h_cmd= 200, cmd=10011
client msg: tnx_id=7, size= 20, h_cmd= 200, cmd=10011
client msg: tnx_id=8, size= 20, h_cmd= 200, cmd=10006
client msg: tnx_id=9, size= 3860, h_cmd= 200, cmd=10002
client msg: tnx_id=10, size= 20, h_cmd= 200, cmd=10006
client msg: tnx_id=11, size= 20, h_cmd= 200, cmd=10008
client msg: tnx_id=12, size= 20, h_cmd= 200, cmd=10006
client msg: tnx_id=13, size= 78, h_cmd= 200, cmd=10002
client msg: tnx_id=14, size= 50, h_cmd= 200, cmd=10002
client msg: tnx_id=15, size= 20, h_cmd= 200, cmd=10008
client msg: tnx_id=16, size= 20, h_cmd= 200, cmd=10006
client msg: tnx_id=17, size= 20, h_cmd= 200, cmd=10006
client msg: tnx_id=18, size= 20, h_cmd= 200, cmd=10003
client msg: tnx_id=19, size= 6900, h_cmd= 200, cmd=10002
client msg: tnx_id=20, size= 20, h_cmd= 200, cmd=10006
client msg: tnx_id=21, size= 39, h_cmd= 203, cmd=24872
client msg: tnx_id=22, size= 20, h_cmd= 200, cmd=10008
client msg: tnx_id=200, size= 30, h_cmd= 200, cmd=10002
*** tnx id sequence error
client msg: tnx_id=201, size= 30, h_cmd= 200, cmd=10002
client msg: tnx_id=202, size= 28, h_cmd= 200, cmd=10002
client msg: tnx_id=203, size= 30, h_cmd= 200, cmd=10002

Does anyone have any ideas? Any help would be much appreciated.

Thanks,

Jeff.
\

On Sat, 29 Jul 2006 12:58:50 -0600, “Jeffrey Adler”
jeffadler.at.bigfoot.dot.com@127.0.0.1 wrote:

Hello all-

I have written a program that sends screen updates from my QNX4 application
to a remote client over TCP/IP. The goal is to replace my applications
console output commands (console_write, etc.) with TCP writes to another
machine, which in turn receives the commands and then does the console
writes itself.

Essentially, I am moving the screen off of the local machine to a remote
machine over TCP.

There is no program acknowledgement between the host and the remote; i.e the
remote client doesn’t specifically acknowledge receipt of the packets from
the host. The host just blindly sends control command packets, much like a
computer talking to a dumb terminal.

The program seems to work just fine if the “remote” program is running on
the local machine and connecting to “localhost”.

When I run the remote “client” program on a remote machine (256KB TCP/IP
connection), I seem to occasionally lose blocks of TCP packets. There
doesn’t seem to be any error returned on the host (that I can tell).
[cat]

Use sniffer maybe client lost packet or server don’t send it.

Marek