Post by: Initial on April 30, 2005, 12:11:00 PM
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]
<
Post by: Dolfhin on April 30, 2005, 02:13:00 PM
QUOTE(Initial @ Apr 30 2005, 05:06 PM)
Please explain, what is the difference and in which way is it less laggy?
Post by: Initial on May 03, 2005, 07:43:00 AM
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]
<
Post by: netdroid9 on May 04, 2005, 04:01:00 AM
Of course, this is a LAN kinda tunnel software, so it'd be easy to find out who's screwing with the packets :). <
Post by: Initial on May 04, 2005, 07:43:00 AM
-Initial
<
Post by: Dolfhin on May 04, 2005, 11:20:00 AM
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.
Post by: Dolfhin on May 04, 2005, 12:41:00 PM
Post by: Bio}{azard on May 17, 2005, 04:57:00 PM
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.
<
Post by: masterdave on May 17, 2005, 07:08:00 PM
Post by: Initial on February 03, 2020, 07:44:00 AM
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]
<
Post by: AXE Clan on May 20, 2005, 07:26:00 PM
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.
Post by: Initial on May 22, 2005, 09:57:00 AM
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]
Post by: flat235 on May 23, 2005, 12:36:00 AM
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
Post by: Initial on May 23, 2005, 07:54:00 AM
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]
Post by: flat235 on May 23, 2005, 08:40:00 AM
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.
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++
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
Post by: flat235 on May 23, 2005, 01:15:00 PM
I would day that the decision to separate in that fashion is one of the reasons Kai 7 has overtaken XBC as the dominant tunnel at the moment - and believe it or not, I didn't even plan to do it.. lol.. It was an afterthought which just got lucky I guess..
TD
Post by: Initial on May 23, 2005, 04:33:00 PM
My message definitions between the UI/CORE/Server or all very proprietary and pain staking to create. I might of been better to use an ASN.1 compiler to generate all the stubs. Instead I've handcoded all the structures. Adding a new message which propagates from the UI to the CORE to the Server and back again takes an eternity. Do you have any thoughts on this?
-Initial
Post by: flat235 on May 24, 2005, 04:23:00 AM
Although, because traffic between UI and Engine is low, and of the lowest priority, I actually just send the messages as delimited strings.. ie:
KAI_CLIENT_PING;Initial;50;
etc.
I suppose it would be "cleaner" to use proper byte packed structs with everything in - but as you say, it's a pain in the ass, especially when going up to server and back. It also makes sense to other people more easily. For example, that line above is absolutely obvious, even to a fledgling coder - give him a simple int parseMessage(char* sMessage); and he can make a UI.
While the players state is always stored on the orbital, we try to keep as much cached in the engine as possible - for example, if the UI needs to ask what arena he's in, we go UI <--> Engine <--> UI, as opposed to UI <--> Engine <--> Orb <--> Engine <--> UI.... even though the players arena state is only *really* known by the server.
My biggest headache with the thing was getting the orbitals talking to each other properly - imagine one guy signing in on Orb A. He has 23 contacts - they are all on one of 13 other orbs.. the orbs must a.) Find them, b.) Check if you're meant to be on their list, c.) Get their IP info and d.) Get that back to the calling engine. Given that these boxes are not dependant on the main TX server, and everything must be 100% guaranteed coordinated (or we start seeing artefacts like wrong arena counts, etc.) - it's a pig of a thing to code.
TD
Post by: Initial on May 25, 2005, 06:23:00 AM
Like your UI, the xmelee UI is as dumb as can be. It has no intelligence, keeps very little internal data. It always has to go to the CORE to proceed in any way. All the intelligence is in the CORE and GSERVER. I also cache data in the core (such as the hosted games). As an example, if the UI doesn't need to know the IP address of another gamer, it doesn't have it. It's all contained in the CORE and hidden from view, the UI only references a game ID.
Architecturally, xlink and xmelee are quite similar. Where the divergence happens, is in the ellaborate orbital server concept you have. Xmelee is still very much dependent on 1 centralized server.
If anyone reading this thread has any ideas (or experience) regarding distributed node servers and how it could apply to this type of software, I'd like to hear it.
Regards,
-Initial
Post by: stevesmename on August 02, 2005, 01:01:00 PM
It is exactly what i've been looking for!
Good Work, and I hope you get some helpful people to your site, to work on better mods.
I've been wanting to start my own game server for awhile, so this is perfect to get started.
I must say the best thing with this is that it is OPEN SOURCE, that is the shiznit!
Good Work!
Post by: darkbowsee on August 04, 2005, 08:10:00 AM
Xmêlée Main Page
Xmêlée Forums
The site is hosted on Sourceforge, all code is released on GPL license, visite us!
Post by: outlook on October 05, 2005, 11:08:00 PM