CL_NetSession for 2.0.2

[catch22]

Hi, I think this question might go directly at Magnus (but anyone chime in if you are certain). I noticed the way packets work are changed and the NetSession module itself is changed a bit.

Is this complete and ready for exploring? If I dug around and tried to do a demo and a write up on it, would I hit any major road blocks preventing me from doing so?

Just curious before I get knee deep in and realize it wasn't quite ready yet.

Thanks.

[Magnus Norddahl]

The NetSession classes in the 2.0 series have an empty implementation that does nothing. They show how I intended to code an initial NetSession API, but since then I've abandoned that project. The classes are therefore currently pending for removal.

The only higher level networking construct implemented in 2.0 is the NetGame API.

[catch22]

That is what I was afraid of. I did spy the code and figured such, but I wanted to be sure.

Thank you for the prompt reply.

That being the case, from what I can tell, the NetGame API is very savvy, though it appears to be TCP only and sends marshalled XML data per event? Is that right?

Is there any kind of estimate on the packet size (without arguments)?

As much as I enjoy the NetGame API (it is splendid), a fast, lightweight connectionless network feature would be ideal for some games (or even a mixture... events handle virtually everything great, but fast positional updates, perhaps might be a concern in the overhead department?). I suppose I'm free to implement it myself :) Or just use the low level wrappers (shucks, because the netsession stuff was pretty robust).

Right now I'm sending movement updates through the event system, so size is a concern for me as I proceed forward, as is speed (it seems fast enough, but it's my local machine of course). I couldn't tell off hand from the code what the approximate overhead is.

I'm trying for a fairly lean networking system to try to get a decent amount of players all connected to one server (I don't know if I'd say MMO, but more than 10, probably in the range of 100). I might also be interested in implementing some unsigned or long integers as arguments in the NetGameAPI, I'm not sure if I do, will you guys patch that or am I just running my own version of clan lib at that point? (or should I be looking into compacting or compression?)

The main reason for that, is time. Most timers like big numbers (doubles, uint64) for time, and I need to be sending time along with my updates. RIght now I'm using floats because that is what's there, but at some point, it may be necessary (or not?) to send along the bigger data type (or I could just restart the server more frequently).

Anyway, apologies for my brain dump... sometimes I just ramble on and on :)

[catch22]

Oh, I Just got the latest SVN and you've added unsigned int to the CL_NetGameEventValues.

Awesome! =D

[sphair]

I'm also using the NetGame api for an online game with pretty much the same requirements as yourself, Catch. For now ClanLib is using an XML serializer to send the data, but when this becomes a bandwidth problem, we'll probably code a binary formatter to use with NetGame API.

I suggest you just continue working on your game, and once you have a specific problem or go live with your game, I'm sure ClanLib will have some solutions for your specific performance or bandwidth problems.

[Magnus Norddahl]

Yes, currently it uses XML to exchange data, but that is only because the original game (DiceWar) didn't have much events to exchange and it therefore was easier.

It doesn't really require much to switch to a binary protocol - basically only two routines needs to be changed. It is just that its quite boring to write the code that registers event names as atoms on first transfer, and then sends a single byte saying what event type it is - and for integers to be compressed so they only take more space than a single byte when the value held is large, etc.

So I will probably not get to that myself until sphair's project reaches a stage where he starts bugging me about the high traffic :)

[catch22]

Thank you both for the input!

[Fr3DBr]

Interesting, so i will go for my own socket implementation for the time being, i guess it will be cool :).

Thanks for the information ! :wheelchair: