Need sleuth for UDP blues.
Need sleuth for UDP blues.
- Subject: Need sleuth for UDP blues.
- From: Graham Parkinson-Morgan <email@hidden>
- Date: Wed, 24 Mar 2004 16:52:37 -0800
I have a problem regarding UDP datagrams in OpenTransport that has
stopped me dead in my tracks.
I have inherited code from an erstwhile colleague, so the scenario
should be familiar.. trying to fix the bugs of a long departed soul.
This is made especially difficult as networking is not my forte, so
here I am, and here is the problem. Hopefully this will turn out to be
blindingly obvious to most people here.
The piece in question is serial number checking code.
What happens is that when the application launches, it announces itself
on the local subnet by broadcasting a UDP packet to port P, then
listens on port P for any replies: by this means it is able to discern
if the licensed runcount is under or oversubscribed, and either runs or
lets the user know the situation.
The original bug was fixed, but under stress testing, a new twist has
emerged and I need help.
The Mac version runs on OS9 and OSX via Carbon. It uses OpenTransport.
It runs asynchronously with no blocking, and no deferred tasks or
threads.
It handles everything in the OTNotifier callback.
Inside there, if it gets a T_DATA message, it calls OTRcvUData to get
the data, checks the error return and flag for T_MORE, and loops until
all data fetched or error.
Care is taken to use OT memory management throughout (the bug fix was
that we were using C++ STL containers to store data inside
OTNotifyProc, which had the potential with large installations to cause
the 'new' memory pool to expand at interrupt time). Something else that
might be useful to know is that there is only one listening endpoint
bound to the machines IP and port P for this process.
I have a test rig running on Mac A and Mac B, a PC, and everything and
its dog is logged to file, including error returns and all entries into
OTNotifyProc. I am testing this on OSX10.3.3. I have tcpdump running in
a terminal window.
When I broadcast one 64 byte packet at a time (from the PC, for the
sake of argument) onto the local network, the OTNotifyProc is called
with T_DATA, the 64 bytes of data are fetched, and everything works
wonderfully well. Mac A and Mac B both see the packet. Likewise, if I
broadcast a single packet at a time from Mac A or Mac B, the other
Mac and the PC pick it up no problem. I moved on to test broadcasting
100 packets from Mac A. The PC picks up all 100 packets: but Mac B
picks up only the first packet: OTRcvUData is successful; flags return
0, and the callback completes. But OT appears to get stuck with the
next packet (just guessing). Even if I go back to broadcasting just one
packet at a time from the PC, Mac B's OTNotifyProc never gets called
again. No crash. No instability. Nothing. Meantime tcpdump tells me
that all 100 UDP packets on port P are arriving from the PC just fine.
Anything else you need to know? (On OSX the OTNotifyProc tops and tails
itself with an OTEnterNotifier/OTLeaveNotifier critical section in case
that is important).
Any help here would be greatly appreciated.
___________________________________________________________________
Graham Parkinson-Morgan
http://www.alap.com
a lowly apprentice production, inc.
5963 La Place Court Suite #206 Voice: 760.438.5790
Carlsbad, CA 92008-8823 Fax: 760.438.5791
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.