I’m having two problem with TCP/IP (either 4.25 or 5.0). These problem
do not show in QNX6 or Windows.
First problem is if I send() a block of 300K (apparently anything bigger
then 65K)
the receving end gets all the data but it’s corrupted,looks like it’s out of
order ;-(
All this with TCP not UDP.
Second problem which has already been discussed in other post:
Unless the connection is kept alive by sending data at least
every 300ms, the first send() will take a very long time compare to
all subsequent send(). TCP_NODELAY doesn’t improve the situation.
Again I want to point out these problems do not show in other OSes,
including QNX6.
Mario Charest postmaster@127.0.0.1 a écrit dans le message :
afcp4h$c13$1@inn.qnx.com…
I’m having two problem with TCP/IP (either 4.25 or 5.0). These problem
do not show in QNX6 or Windows.
First problem is if I send() a block of 300K (apparently anything bigger
then 65K)
the receving end gets all the data but it’s corrupted,looks like it’s out
of
order ;-(
All this with TCP not UDP.
Second problem which has already been discussed in other post:
Unless the connection is kept alive by sending data at least
every 300ms, the first send() will take a very long time compare to
all subsequent send(). TCP_NODELAY doesn’t improve the situation.
Again I want to point out these problems do not show in other OSes,
including QNX6.
I see
Actually, the second problem is also encontoured with RTOS 6.2 as i
experienced.
“inn.qnx.com” postmaster@127.0.0.1 wrote in message
news:afgm5b$8pt$1@inn.qnx.com…
Mario Charest postmaster@127.0.0.1 a écrit dans le message :
afcp4h$c13$> 1@inn.qnx.com> …
I’m having two problem with TCP/IP (either 4.25 or 5.0). These problem
do not show in QNX6 or Windows.
First problem is if I send() a block of 300K (apparently anything bigger
then 65K)
the receving end gets all the data but it’s corrupted,looks like it’s
out
of
order ;-(
All this with TCP not UDP.
Second problem which has already been discussed in other post:
Unless the connection is kept alive by sending data at least
every 300ms, the first send() will take a very long time compare to
all subsequent send(). TCP_NODELAY doesn’t improve the situation.
Again I want to point out these problems do not show in other OSes,
including QNX6.
I see >
\
Previously, Ron Cococcia wrote in qdn.public.qnx4:
Hi,
I’m writing a diagnostic program for our product, and one thing I’d like to
do is determine if the loader is QNX or not. What methods can I use to
determine if the QNX loader is being used?
TIA,
Ron
One way would be to read block 0 of the hard disk (/dev/hd0) and
scan it for the string QNX.
“Pascal Bouchard” <pasbou@fenclo.com> wrote in message
news:agib51$1nj$1@inn.qnx.com…
Actually, the second problem is also encontoured with RTOS 6.2 as i
experienced.
Yep my mistake. With 6.2 delay is not there if using 127.0.0.1 but it’s
there if using ip address of interface. (running server and client on same
machine)
“inn.qnx.com” postmaster@127.0.0.1 wrote in message
news:afgm5b$8pt$> 1@inn.qnx.com> …
Mario Charest postmaster@127.0.0.1 a écrit dans le message :
afcp4h$c13$> 1@inn.qnx.com> …
I’m having two problem with TCP/IP (either 4.25 or 5.0). These
problem
do not show in QNX6 or Windows.
First problem is if I send() a block of 300K (apparently anything
bigger
then 65K)
the receving end gets all the data but it’s corrupted,looks like it’s
out
of
order ;-(
All this with TCP not UDP.
Second problem which has already been discussed in other post:
Unless the connection is kept alive by sending data at least
every 300ms, the first send() will take a very long time compare to
all subsequent send(). TCP_NODELAY doesn’t improve the situation.
Again I want to point out these problems do not show in other OSes,
including QNX6.
I see >
\