xmelee does package it up as soon as it can, what it does do is catch up if there is alot of data to send and then spew it out in individual 500k multi frame packets. I'm not adding latency by polling periodically, I'm just packaging up everything into one packet if there are multiple packets in the buffer by the time I get to them. (This could be caused by a hick up on the users computer or something else).
I see - that's a sensible approach for sure, but from the data we gathered when playing with the same thing, we *never* got a queue on the sniffer side. Saying that though, our stuff is geared up to give total priority to the sniffer <--> udp socket stuff - the gameserver and ui stuff can wait. I guess it depends how your engine model works. We spent a lot of time trying what you suggest with the gamecube - because it sends a *hell* of a lot of *really* small packets - even then, we reckoned it was faster jsut to watch the sniffer like a hawk, and shoot anything out as soon as it comes in - avoiding the queueing.
I'm not saying its not a valid approach - it most certainly is, but it would be interesting to see in what games the benefit is most apparent.
There is also one big difference between xlink, xbc and xmelee... I'm just ONE guy with another job.
I hear that
I started out just the same.. We all still have normal jobs, but it's nice now we have a load of other guys contributing.
I have the game server and packetization core in a rock solid state, but I'm terrible at User Interface stuff. The UI was to be short term.. I would really need someone to take over that code (and even the game server code) and then I could concentrate on the packetization core and a distributed game server model.
When I originally sketched out the architecture, I broke it down into 3 individual blocks with different development environments. I've kept it this way, but it does make development rather painfull when you are one person.
Yeah Kai's architecture is pretty similar.. the distributed orbital mesh os probably the strongest feature at current - allows us to give a much richer flow of data back to the engine than any other similar app. I also know the feeling with UI - I made the current win32 one, and it's very much a "coders" UI - kinda pretty, but basically functional and no more.. The UI's made by proper UI guys (XBMC, Amaryllis, jKaiUI, gKaiUI) are all much better - we're lucky to have those guys help.
UI - Visual Studio .NET C#
Core - Win32 Console app C++ (should be portable to a mac/linux client)
gserver - cygwin and linux C++
Sorta the same.. but eww.. .NET
:D ? WHY??
UI - VC++
Engine - VC++
Orbital Server - VC++
Root box - PHP+MySQL over IIS6/2k3
Your project sounds good - its nice to see someone still trying to get more out of the theory behind the tunnel itself. We were pretty much where you are now back in the day, and we found a lot of new stuff out - and everyone told us we were a.) Lying, b.) Sucked, c.) Had no users d.) Would be gone in 6 months.
I'm pleased to say that didn't happen, but it was hard work. Ignore what anyone else really says - if you enjoy the work, do it - and remember the age-old hobbyist coder adage: "If you build it, they will come"