What is the engine doing with datagram sockets?

[RCS]

I have been using sockets successfully (in MC and RunRev) for quite a while
now...it is one of their strengths. Now I need to use datagram sockets, (in
particular 'broadcasting') and I am discovering that this seems to be very
different...and I cannot get datagram broadcasting working in Linux at all
(error 13).

In all fairness, it seems like opening a 'single' specific datagram socket
works like a regular socket...but what I am trying to accomplish is
broadcasting on 255.255.255.255 to a specific port for multiple devices, and
it is very strange:

(Windows XP - engine 2.5 or 2.5.1)
- My broadcast computer generates it's own 'alias' datagram socket, and
sends the data back to itself.
- Since it does this, it gets to my 'receiving' handler first, and stops
anything else from coming in:

local udpSocket

on mouseUp
 put into "255.255.255.255:199" udpSocket
 open datagram socket to udpSocket  with message "ACCEPTED"
 accept datagram connections on port "199" with message "ACCEPTED"
 write "Roll Call" to socket  udpSocket  with message "getData"
 send "resetUDP" to me in 50
end mouseUp

on ACCEPTED s,data
  put RETURN & s && data after message -- for testing
end ACCEPTED

on getData s,data
  put s && data & RETURN after message -- for testing
end getData

on resetUDP
  close socket udpSocket
end resetUDP

If I use the above script to broadcast to multiple devices, only the
originating computer gets to the 'ACCEPTED' handler the first time (with
it's 'alias' address)...what I discovered is, that I must close the socket,
and repeat this process twice to get 'any' of the information from the other
devices (basically pressing the button twice). But it really is worse than
that...I must parse each response after that, and generate a listening port
for each device:

on ACCEPTED s,data
  set itemDelimiter to ":"
  put item 2 of s into thePort
  startListeningTo thePort
end ACCEPTED

on startListeningTo thePort
  if thePort is NOT among the lines of the openSockets then
   accept datagram connections on port thePort with Message "tryItAgain"
  end if
end startListeningTo

on tryItAgain s,data
  if "OK" is NOT among the words of data then -- the devices respond with
"OK"
  write "ROLL CALL" to socket s with message "getData"
  end if
end tryItAgain

This actually works (this script is written from memory however...but the
'theory' is here), and I can now do my UDP broadcast (but only on XP so
far). My question is...what is the engine doing with datagram sockets? Is
this really how I must handle multiple responses from a broadcast? Has
anyone had any better success at doing this?

Here is what I believe the problem is:

Opening a broadcast datagram socket is not really connecting to anything
specific, so the MC/RunRev engine is somewhat in 'oblivion' about what is
going on...and it generates it's own internal connection socket in response
to receiving data on the listening port (becoming one of the responding
devices). When multiple devices respond on the same port (i.e. receiving
many messages on a datagram port) the engine is only accepting the 'first'
one (itself), and ignoring the rest...but the data is in a buffer somewhere.
So, when I close the socket, and reopen, the data that was 'buffered' is
ready to be 'read' again.

Hopefully, someone will look at this and say "you need to do this" , and
everything will work. But, I have been through this enough now to feel that
something else is happening 'behind the scenes' that I just don't have
enough information about.

Thanks for any info,

JR