www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2002/12/20/01:31:13

Lines: 42
X-Admin: news AT aol DOT com
From: dang2015 AT aol DOT com (DanG2015)
Newsgroups: comp.os.msdos.djgpp
Date: 20 Dec 2002 06:29:12 GMT
Organization: AOL http://www.aol.com
Subject: WATT32 test app & DJGPP
Message-ID: <20021220012912.26934.00000420@mb-dh.aol.com>
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

I'm having a problem with WATT32 and was wondering if anyone might glance at
this and say "oh, right... you need to do XYZ".

I'll spare a ton of details just to see if there's something at a really high
level that someone recognizes.

We have a little Win test app we've used for awhile to toss UDP packets from
one machine to another (e.g., Win to Win, Win to QNX) and we'll have the other
platform just echo them back - just a little traffic generator test.

I recently built the latest release of WATT32 with the latest DJGPP (it's nice
to have stuff compile clean right out of the box, BTW) and compiled and linked
the UDP_SRV.C test app.  I chose this one because it does just echo the packet
back to the sender and would be compatible with our test app.

Here's the issue... if I remove the sendto( ) call, and just print the packet
as received, it will work forever.  I can toss hundreds of packets at it and it
just tells me about receiving each one.  But if I put the sendto back in, it
will echo ONE packet back.  And after that, it will not receive again.

I've checked all the "normal" stuff... packet too big for the buffer, etc., and
see nothing.  It doesn't crash... it just blocks forever in the recvfrom( )
call.  I added some fcntl code to make the call non-blocking, and it just loops
forever around the (now non-blocking) recvfrom( ) never getting a packet out of
the call after the first sendto( ).

[e.g., I had it reply to the sender after getting 10 packets and we get 10
incoming, then ourtest app does get and show the one reply, then nothing more
in response to sending more packets at UDP_SRV]

I'm running in a DOS window under Win98 right now, and I've tried several
different 3C509 packet drivers... with identical results.  I'll try a plain DOS
box in the AM, but I'm betting I'll see the same results.

I've dug into the WATT32 code a little and some printf's show that a packet
does arrive, but it gets discarded along the way...  I'm hoping someone sees
this and remembers a similar wrestling match... if not, I'm going hunting in
the morning!

Thanks in advance,

Dan

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019