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
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
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
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.
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