Hi everyone, thanks for all the input > Message: 4 > Date: Wed, 24 May 2006 08:26:02 +1000 > From: James Cameron <quozl at us.netrek.org> > Subject: Re: [netrek-dev] Number of players on Vanilla Server > > Chris, the specification of the protocol is in the source code for the > server, Yeah that's what always tell my boss when i asks for documentation :-) > you should read and understand the relevant sections as soon as > yohu have a question about how the protocol works. It's comming, but quite a bit to chew on from scratch. > MAXPLAYER is set in include/config.h to 32. That's player number zero > through to 31, as you observed. Yes there were some very helpfull remarks as to why. I've created a larger array, but now also know why :-) > How far are you from release? We're synchronising here for a 1st June > release for several components. Very far, but i could help generate a server binary for OS X if you would like? > -- > James Cameron mailto:quozl at us.netrek.org http:// > quozl.netrek.org/ > > > > ------------------------------ > > Message: 5 > Date: Wed, 24 May 2006 08:34:36 +1000 > From: James Cameron <quozl at us.netrek.org> > Subject: Re: [netrek-dev] Connection to server protocol > > G'day Chris, > > No, tcpdump doesn't really help me ... I use packet decoding logic in > the Linux client to figure out what is going on. We don't have > this in > the server yet, but it's something I'm pondering. Ok, i created a something and hooked it quite ugly i gwrite, i will post it later on, could be something to bolt on but it is not as descriptive as your log > On Sat, May 20, 2006 at 10:50:24PM +0200, Chris en Judith wrote: >> roughly the server responds to my CP_SOCKET and CP_FEATURE message >> with a SP_MOTD and a SP_MOTD_PIC the remainder of the buffer is >> filled with a 0 and gets flushed. (i might accidently have read an >> entire frame 1536 in stead of what was really in the buffer but >> what the hack. > > You'd better clarify this. Packets are sent appended to each > other, and > unless you get the sizes exactly right (their size is not in the data > stream usually) then you will lose alignment and crash. My mistake, i advanced a pointer a bit too far, and had not expected the server to cache that many messages. They are flying by now. >> i was expecting a message SP_S_PLAYER to set which slot i'd been >> allocated but i might be fully off here. > > After SP_MOTD you get SP_YOU with your player number, then a batch of > (SP_PL_LOGIN, SP_HOSTILE, SP_PLAYER_INFO, SP_KILLS, SP_PSTATUS and > SP_PLAYER) for each of the 32 slots. Then you get all the > SP_PLANET_LOCs for each planet, then all the SP_FEATURE packets, > then an > SP_LOGIN prompt packet. Your reply at this point should be CP_LOGIN. I'm at that stage now, what tricked my was the CP_SOCKET i had not anticipated the need before the server even nows my name, then i saw the UDP version field... > See http://quozl.linux.org.au/netrek/login.log.gz for an example of a > connection and login sequence. Got it, these SP_SEQUENCE had to do with compressed packets isn't it? Thanks i'll keep you posted on the progress. regards Chris