From: Kenny Tilton
Subject: OT: datagram sockets
Date: 
Message-ID: <3F3E576E.2040405@nyc.rr.com>
Not Lisp, but there is no comp.sockets NG, and you all seem to know 
lots, so here goes:

Running soccer server and Lisp client on same box. On both combos 
ACL+acl::socket+win32 and cmu+db-sockets+linux (and diff versions of the 
server!), the server quickly falls silent after a few exchanges of 
messages over the UDP datagram sockets.

Dropping the priority on ACL to low and running cmu "nice" makes 
everything work just dandy.

Note that this does not seem to be a case of the server missing 
something I simply need to resend. I am aware udp is unreliable. 
Sometimes the server falls silent after I receive just a few of about a 
dozen messages always sent at start-up. ie, it ain't waiting for a 
handshake.

I have the priority/nice workaround, but my concern is that that just 
happens to alter things enough that the real problem is masked, and that 
the real problem will reappear at some inopportune moment, such as the 
ILC2003 finals against TeamBastards. :)

-- 

  kenny tilton
  clinisys, inc
  http://www.tilton-technology.com/
  ---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
                                                  -- Bob Uecker

From: Greg Menke
Subject: Re: OT: datagram sockets
Date: 
Message-ID: <m3brup1oay.fsf@europa.pienet>
Kenny Tilton <·······@nyc.rr.com> writes:

> Not Lisp, but there is no comp.sockets NG, and you all seem to know
> lots, so here goes:
> 
> Running soccer server and Lisp client on same box. On both combos
> ACL+acl::socket+win32 and cmu+db-sockets+linux (and diff versions of
> the server!), the server quickly falls silent after a few exchanges of
> messages over the UDP datagram sockets.
> 
> Dropping the priority on ACL to low and running cmu "nice" makes
> everything work just dandy.
> 
> Note that this does not seem to be a case of the server missing
> something I simply need to resend. I am aware udp is
> unreliable. Sometimes the server falls silent after I receive just a
> few of about a dozen messages always sent at start-up. ie, it ain't
> waiting for a handshake.
> 
> I have the priority/nice workaround, but my concern is that that just
> happens to alter things enough that the real problem is masked, and
> that the real problem will reappear at some inopportune moment, such
> as the ILC2003 finals against TeamBastards. :)


I'd bet on a deadlock which is avoided by the timing change caused by
you changing the task priorities.  Have you sniffed the network,
tcpdump etc... to see whats happening, and what retry policies have
you implemented?

UDP on the wire is reliable in terms of signalling if you're using a
switch.  But you're still subject to the buffering policies of the
stacks on both ends- which potentially extends to localhost exchanges
on a single host.

Gregm
From: Kenny Tilton
Subject: Re: OT: datagram sockets
Date: 
Message-ID: <3F3E5E4C.5050105@nyc.rr.com>
Uh, the question was, "Does this ring a bell with anyone? Any 
info/thoughts/guesses or weird workarounds welcome."

:)

kt

Kenny Tilton wrote:
> Not Lisp, but there is no comp.sockets NG, and you all seem to know 
> lots, so here goes:
> 
> Running soccer server and Lisp client on same box. On both combos 
> ACL+acl::socket+win32 and cmu+db-sockets+linux (and diff versions of the 
> server!), the server quickly falls silent after a few exchanges of 
> messages over the UDP datagram sockets.
> 
> Dropping the priority on ACL to low and running cmu "nice" makes 
> everything work just dandy.
> 
> Note that this does not seem to be a case of the server missing 
> something I simply need to resend. I am aware udp is unreliable. 
> Sometimes the server falls silent after I receive just a few of about a 
> dozen messages always sent at start-up. ie, it ain't waiting for a 
> handshake.
> 
> I have the priority/nice workaround, but my concern is that that just 
> happens to alter things enough that the real problem is masked, and that 
> the real problem will reappear at some inopportune moment, such as the 
> ILC2003 finals against TeamBastards. :)
> 


-- 

  kenny tilton
  clinisys, inc
  http://www.tilton-technology.com/
  ---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
                                                  -- Bob Uecker
From: Joe Marshall
Subject: Re: OT: datagram sockets
Date: 
Message-ID: <isouyfd7.fsf@ccs.neu.edu>
Kenny Tilton <·······@nyc.rr.com> writes:

>> Running soccer server and Lisp client on same box. On both combos
>> ACL+acl::socket+win32 and cmu+db-sockets+linux (and diff versions of
>> the server!), the server quickly falls silent after a few exchanges
>> of messages over the UDP datagram sockets.

> Uh, the question was, "Does this ring a bell with anyone? Any
> info/thoughts/guesses or weird workarounds welcome."

I once worked on a system where if you didn't explicitly ask for
TCP_IP in the address family, and the machine could deduce that both
processes were on the *same* machine, it would substitute a pipe.
However, the `packet size' for the pipe was smaller than that for the
TCP socket, and it could not be resized the way a TCP socket can be.
So if you got a socket and used SETSOCKOPT to request a packet size
greater than the limit built into the pipe, your process would hang on
read because the pipe wouldn't deliver the data until it had `enough'
and it wouldn't accept any more data because it was `full'.

I doubt this is your problem, but you did ask for weird.
From: Kenny Tilton
Subject: Re: OT: datagram sockets
Date: 
Message-ID: <3F412EBF.8060202@nyc.rr.com>
Joe Marshall wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> 
>>>Running soccer server and Lisp client on same box. On both combos
>>>ACL+acl::socket+win32 and cmu+db-sockets+linux (and diff versions of
>>>the server!), the server quickly falls silent after a few exchanges
>>>of messages over the UDP datagram sockets.
>>
> 
>>Uh, the question was, "Does this ring a bell with anyone? Any
>>info/thoughts/guesses or weird workarounds welcome."
> 
> 
> I once worked on a system where if you didn't explicitly ask for
> TCP_IP in the address family, and the machine could deduce that both
> processes were on the *same* machine, it would substitute a pipe.
> However, the `packet size' for the pipe was smaller than that for the
> TCP socket, and it could not be resized the way a TCP socket can be.
> So if you got a socket and used SETSOCKOPT to request a packet size
> greater than the limit built into the pipe, your process would hang on
> read because the pipe wouldn't deliver the data until it had `enough'
> and it wouldn't accept any more data because it was `full'.
> 
> I doubt this is your problem, but you did ask for weird.
> 

:) Yes, and thx to everyone for their ideas. Turns out "nice"  does not 
suffice on Linux, so I am getting ready to build a server from source 
and take a look at the problem from that perspective. I wager it is 
something simple I am doing wrong that is upsetting the server--that app 
is pretty heavily worked over by all sorts of users/languages.



-- 

  kenny tilton
  clinisys, inc
  http://www.tilton-technology.com/
  ---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
                                                  -- Bob Uecker