Print

[Initial]

If you are interested in running your own xbox tunnel server, the game server (called gserver) of xmelee has been released. You can also get the source code for the end user xbox tunnel client to do your own mods.

The xmelee gserver is probably a great option if you are on a private lan like a university campus and need to run your own server. This will also allow you to play xbox system link games against people in other dorms since the packets are encoded as normal IP/UDP packets (most university campuses don't allow you playing xbox system link games on the internal network).

The xmelee gserver is also usefull for anyone looking to run their own xbconnect like gaming network. With the optional user interface source code, you can distribute your own client for your gaming network and server.

The xmelee packetization core is also less laggy than xbconnect/xlink kai.

[email protected]


 <

[Dolfhin]

QUOTE(Initial @ Apr 30 2005, 05:06 PM)

The xmelee packetization core is also less laggy than xbconnect/xlink kai.

[email protected]

Please explain, what is the difference and in which way is it less laggy?

[Initial]

If you look at xbconnect for one, you can find yourself in situations where users are constantly trying to connect to your game, after you locked the door (because of the old information they have). Alot of this messaging is all TCP based. Communication with the game server as well happens in a TCP fashion, which can cause some retransmits, packet fragmentation and so forth.

From a pure game play experience, if you look at the packetization core. Xmelee always does packetization of mulitple packets within one UDP frame (you don't have to buy the version). the packet sizes are also kept small in order to avoid any fragmentation by any router or other network boxes the packet may encounter when it is transmited from the originator to the destination. It will also catch up with the contents in multiple packets if a hickup occurs on the users box or the network.

The original ethernet frames of the xbox along with the IP, UDP Header and CRC's are also stripped out and recreated at the far end. There is also a very small header 4 bytes used to prefix individual packets. PC's these days are much faster, and you might as well use the CPU to recompute the CRC and rebuild the packet then to send all this data over to the far end and consume extra bandwidths..

There are other minor things I've done as well..

[email protected]
 <

[netdroid9]

Of course, by not CRCing the packets with the original CRC from the host console faulty packets could be accepted as the correct packets, there by allowing, for example, cheaters, to screw with your game.

Of course, this is a LAN kinda tunnel software, so it'd be easy to find out who's screwing with the packets . <

[Initial]

Very true, but I do have some protection in the 4 byte header I use which prefixes the xbox's packet. So the hacker would have to take gain understanding of the header and add his own frame sequence number and so forth..

-Initial
 <

[Dolfhin]

Btw you might want to mail the xbox-scene guys to get this on the frontpage. It will attract more users than just posting it in this forum. The adres can be found on www.xbox-scene.com/about.php if I'm right.

[Dolfhin]

Just wanted to enable E-mail notification ... ignore this post <

[Bio}{azard]

1. XBC's tunnel adds even less overhead then Xmelee. (1 byte). The next version is targeted to actually make the packets smaller by 10 bytes.

2. XBC uses pure UDP for all client to client, room to room communication. TCP is only involved when there is a need to use a service on the XBC server.

3. Packetization, in most cases, introduces lag. Both XBC and Xlink have done this a long time ago. You save bandwidth at expence of adding latency. Halo 2 servers send packets every 40 MS. So for your code to do any good, you would need to add 40 MS ping to everyone for this to even work.


 <

[masterdave]

Very True Bio}{azard <

[Initial]

Bio}{azard,

Fair enough. I have to admit that the last time I looked at xbconnect packet captures and did the math, it was about a year and a half ago.  xmelee is not out there to outdo xbconnect on a technical packetization level, but simply to offer an alternative which permits users to create their own private game server networks such as on a university campus or a clan's private game server (on the internet) which can be linked up with their web server.

[email protected]


 <

[AXE Clan]

 I highly doubt you will go anywhere with your tunnel as both Xlink and XBC users are both set on their tunnel.  Maybe an xbox 360 tunnel but no way are you going to get mass users for an xbox tunnel this late in the game.

[Initial]

AXE Clan,

I agree with what you said, but you are missing the point.

The back end game server is available. If you are on a university campus, or a metro area lan, you don't have great external public internet bandwidth and access, but you do have alot of bandwidth on the internal campus or metro lan. These users are typically excluded from xbc and xlink. With xmelee, the IT administrator or any internal user can setup a game server. No firewal, router, NAT box configs required to forward ports at the edge of the enterprise network.. This is the beauty of xmelee.. A freely available back end game server as well as the client software and user interface source code. (With a top notch tunnel/packetization engine).

Yes, as far a getting critical mass on the public xmelee game server is concerned, that's not going to happen any time soon. But if you are looking to setup your own game server network, what other alternative is there to xmelee? NONE.

Currently, I hold the source code to the packetization core and the gserver. At any point in time, I can sell this to anyone or release the source code to open source. Given a bit of time, this would surely put a big dent in xbc and xlink... it's not my plan at this time (but I'm crazy enough to do it..)

[email protected]

[flat235]

Kai's deep resolution server already does what you're saying on university LANs - has been for some time now. It can even provide dual interface support for the engine, allowing users like Italian Fastweb customers to play against fellow Fastweb users and others at once - even Live! can't do that.

Using DRS with Kai, the engine automatically sends data between same-LAN users over the LAN, and off-LAN data over the internet.

About the packetisation-core stuff. We did it all a couple of years back - and no, it doesn't really work. You will get better results if you concentrate on getting the data in and out of your code as fast as possible - even to the point of *not* removing pointless data from the frames.

A lot of our stuff is opensource already - with more to come. I fail to see how the introduction of another packet core / server model would affect the current demographic - but hey - release it Let's see..

Watching with interest

TD

[Initial]

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'm sure Xlink and the others do the same.

There is also one big difference between xlink, xbc and xmelee... I'm just ONE guy with another job. 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.

UI - Visual Studio .NET C#
Core - Win32 Console app C++ (should be portable to a mac/linux client)
gserver - cygwin and linux C++

[email protected]

[flat235]

QUOTE

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.

QUOTE

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.

QUOTE

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.

QUOTE

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 ? WHY??

We're:

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"

TD