Vanilla Netrek Server Development Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[VANILLA-L:1033] Re: [VANILLA-L:1030] Re: Message loss
Two thoughts:
1 - I was noticing an awful lot of message loss while debugging the server
( and earlier versions of the server). I thought the problem was possibly
fixed with the cambot changes to the socket.c code. I'm not sure what I
changed that effected this part of the code, but playtesting demonstrated a
significant decrease in lost messages.
My test was simple, I would send myself 'help' in the INL Robot
continuously, and then see how corrupted the returned help display was.
Prior to cambot I would start losing messages after buffering two 'help'
commands. After the cambot patches, I was not able to buffer enough
commands to cause message loss. I'm not sure what causes this message
loss, but if I had to offer a guess, I'd suggest a possible overflow of
the message buffer..
> Mikael Sandstr|m writes:
> >
> > I might not be of any relevance. But when I played on real-time I got
> > a message like "GOD->Fa You have been ejected for not reading
> > messages" And Fa was ejected, only problem I was R4 and why did I get
> > this personal message ?
>
> This was a bug with the eject code, which I thought I'd fixed years ago
> on bigbang. Thought that this had been fixed in the main distribution.
> I will try to dig out my source and send to to Bob so he can compare to
> what he's running.
2nd thought - I noticed this while working in socket.c last year. This
happens because of a bug in the message code. A feature was added to the
server that causes eject messages to be flagged with a conquer bit. This
conquer bit is used to force the client to output the eject warning to the
command line. (Thus aiding newbies.) However, since other players found
it annoying to see these messages sent to the all board constantly, a later
patch was introduced to only send the conquer flagged message to the victim
slot. However, the patch was buggy - it altered the global buffer's flag
for that message, sent the message, and then reset the global flag.
Although this would work in a single-tasking environment, in netrek's
multi-process environment, it is possible for another process to read the
global flags and mis-interpret the message while the other process is still
working on "send the message". This poor inter-synchronization is rare, but
I believe it is what causes these odd messages.
I'm not sure if I fixed this in the 2.8pl0 release or not. I'd check, but
I dont have my source tree handy..
Later,
-Kevin
--
------------------------------------------------------------------------
| Kevin O'Connor "BTW, IMHO we need a FAQ for |
| koconnor@acsu.buffalo.edu 'IMHO', 'FAQ', 'BTW', etc. !" |
------------------------------------------------------------------------
+
++ Vanilla-l Mailing List ++
To unsubscribe: send "unsubscribe vanilla-l" to majordomo@real-time.com
For more information: http://archives.real-time.com
References: