xboxscene.org forums

Pages: 1 [2]

Author Topic: Xmelee Xbox Tunnel Client Source Code And Server  (Read 161 times)

flat235

  • Archived User
  • Sr. Member
  • *
  • Posts: 292
Xmelee Xbox Tunnel Client Source Code And Server
« Reply #15 on: May 23, 2005, 01:15:00 PM »

If I may, I'd recommend opening it as TCP or UDP. This gives you true separation between the modules and paves the way for kinky stuff like XBMC's support, and embedded engines on WRT routers etc.

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
Logged

Initial

  • Archived User
  • Newbie
  • *
  • Posts: 12
Xmelee Xbox Tunnel Client Source Code And Server
« Reply #16 on: May 23, 2005, 04:33:00 PM »

Actually, the communication between the UI and the packetization engine is 100% TCP based. It was from day one as well. Even the IP address of where the core resides is configurable (for me). I can run the packet sniffing and packetization on a different PC then the UI. (same as you).

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
Logged

flat235

  • Archived User
  • Sr. Member
  • *
  • Posts: 292
Xmelee Xbox Tunnel Client Source Code And Server
« Reply #17 on: May 24, 2005, 04:23:00 AM »

Not really - because it was a pain the ass for me too biggrin.gif

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
Logged

Initial

  • Archived User
  • Newbie
  • *
  • Posts: 12
Xmelee Xbox Tunnel Client Source Code And Server
« Reply #18 on: May 25, 2005, 06:23:00 AM »

Hmm.. I suppose delimited strings or an API would be similar in the amount of work required. The delimited string would have an advantage over the API in terms of supporting different types of UI's development environments (it's doesn't have to be C structures). I like it, but I'm probably to far down the path to turn back at this point..

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


Logged

stevesmename

  • Archived User
  • Newbie
  • *
  • Posts: 4
Xmelee Xbox Tunnel Client Source Code And Server
« Reply #19 on: August 02, 2005, 01:01:00 PM »

Great Idea Initial!

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!

 beerchug.gif
Logged

darkbowsee

  • Archived User
  • Newbie
  • *
  • Posts: 6
Xmelee Xbox Tunnel Client Source Code And Server
« Reply #20 on: August 04, 2005, 08:10:00 AM »

Hi, I'm BigBowser (even i'm logged in darkbowsee), I'm the web administrator of the Xmêlée project, and I'm here to say one thing: the Xmêlée Web Site is now open!

Xmêlée Main Page
Xmêlée Forums

The site is hosted on Sourceforge, all code is released on GPL license, visite us!
Logged

outlook

  • Archived User
  • Newbie
  • *
  • Posts: 1
Xmelee Xbox Tunnel Client Source Code And Server
« Reply #21 on: October 05, 2005, 11:08:00 PM »

I have been using it. pst recovery and dbx reader more stable and secure than other programs.
Logged
Pages: 1 [2]