UDP broadcast problems

Hello there,
The application I develop is a distributed application running on 4 SBC’s
under QNX4.25J, connected via 10 Mbit ethernet line- 10Base2 (using TCPIP
4.25B stack ).
A unique “main_process” is running on SBC1, prepares a buffer of commands
and broadcast it to the other SBS’s via UDP socket. The buffer size is less
than 1300 bytes. Each buffer has it own application counter, which is
incremented evry send. Other parts of the application running on the other
SBC’s process this data. This processing is timed by an external interrupt
evry 75 miliseconds.
The other SBS’s got the data by polling a UDP socket in non blocking mode.
There are no router. Each node runs locally Socklet.

Using sniffer recordings the following phenomenons are observed:

  1. Buffers order is changed ( “new” buffer is broadcasted before “old”
    buffer )
  2. Buffer already transmitted on time is retransmitted again after about 1
    second.

Can these phenomenons be caused by a bug in the adapter driver or,
is it a bug in the protocol stack?
Is there any interaction between run time parameters of Net, Proc32 ,
Socklet and other system process that can cause such phenomenons?

Thanks,
Rami Raviv

Have you tried using socket instead of socklet. My programs broadcast
on UDP and I have never seen something like this before, but I use socket.

elisra wrote:

Hello there,
The application I develop is a distributed application running on 4 SBC’s
under QNX4.25J, connected via 10 Mbit ethernet line- 10Base2 (using TCPIP
4.25B stack ).
A unique “main_process” is running on SBC1, prepares a buffer of commands
and broadcast it to the other SBS’s via UDP socket. The buffer size is less
than 1300 bytes. Each buffer has it own application counter, which is
incremented evry send. Other parts of the application running on the other
SBC’s process this data. This processing is timed by an external interrupt
evry 75 miliseconds.
The other SBS’s got the data by polling a UDP socket in non blocking mode.
There are no router. Each node runs locally Socklet.

Using sniffer recordings the following phenomenons are observed:

  1. Buffers order is changed ( “new” buffer is broadcasted before “old”
    buffer )
  2. Buffer already transmitted on time is retransmitted again after about 1
    second.

Can these phenomenons be caused by a bug in the adapter driver or,
is it a bug in the protocol stack?
Is there any interaction between run time parameters of Net, Proc32 ,
Socklet and other system process that can cause such phenomenons?

Thanks,
Rami Raviv





\

THank You,
I tried also socket and then TCPIP 5 and got the same phenomenons.

Rami Raviv

Dave Allamby <allambyjd@cyradis.com> wrote in message
news:3DD1ACAE.5040704@cyradis.com

Have you tried using socket instead of socklet. My programs broadcast
on UDP and I have never seen something like this before, but I use socket.

elisra wrote:

Hello there,
The application I develop is a distributed application running on 4
SBC’s
under QNX4.25J, connected via 10 Mbit ethernet line- 10Base2 (using TCPIP
4.25B stack ).
A unique “main_process” is running on SBC1, prepares a buffer of commands
and broadcast it to the other SBS’s via UDP socket. The buffer size is
less
than 1300 bytes. Each buffer has it own application counter, which is
incremented evry send. Other parts of the application running on the
other
SBC’s process this data. This processing is timed by an external
interrupt
evry 75 miliseconds.
The other SBS’s got the data by polling a UDP socket in non blocking
mode.
There are no router. Each node runs locally Socklet.

Using sniffer recordings the following phenomenons are observed:

  1. Buffers order is changed ( “new” buffer is broadcasted before “old”
    buffer )
  2. Buffer already transmitted on time is retransmitted again after about
    1
    second.

Can these phenomenons be caused by a bug in the adapter driver or,
is it a bug in the protocol stack?
Is there any interaction between run time parameters of Net, Proc32 ,
Socklet and other system process that can cause such phenomenons?

Thanks,
Rami Raviv







\

Using sniffer recordings the following phenomenons are observed:

  1. Buffers order is changed ( “new” buffer is broadcasted before “old”
    buffer )
  2. Buffer already transmitted on time is retransmitted again after about
    1
    second.

I’m not sure what you’re seeing is wrong - since UDP isn’t reliable (not
gauranteed to make delivery). At the very least, you’d have to take into
account that broadcasts can’t be transmitted.

Can these phenomenons be caused by a bug in the adapter driver or,
is it a bug in the protocol stack?
Is there any interaction between run time parameters of Net, Proc32 ,
Socklet and other system process that can cause such phenomenons?

Since you actually haven’t posted what the network chip set is, I can’t say
if there has been improvements to the driver for known issues.

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>