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