Print

[flat235]

Anyway - lets forget all that shit, I hope you can get this thing going - and I will try to help as much as I can, time permitting...

The protocol itself is, as far as i can tell, almost complete, as of revision 27.. although it will be optimised now to reduce server load - which may affect some calls (most notably fold some 2 segment PHP calls into 1 etc.)

I will then create a seperate server instance for your development.... subsituting"27" in all the filenames for "27exp" or something... Then I think we would be safe to start looking at protocol implementations...

TD

[flat235]

ATTN: jhurliman

Here is it.. in a sort of pseudo-code..

The prepended chr(99) distinguished this xbox data as "Messenger mode" .. as opposed to other modes...

strip(raw as SIMPLEBYTEARRAYTHING)
{

output = Chr(99) + left(raw, 14) + Mid(raw, 17, 4) + Mid(raw, 25, 2) + Mid(raw, 31, 1) + Mid(raw, 39)

return output;
}


synth(RAW AS STRIPPEDBYTEARRAY)
{
output = left(raw, 14) + Chr(69) + Chr(0) + Mid(raw, 15, 4) + Chr(0) + Chr(0) + Chr(64) + Chr(17) + Mid(raw, 19, 2) + Chr(0) + Chr(0) + Chr(0) + Chr(1)

If Mid(raw, 21, 1) = Chr(255) Then
output = output + Chr(255) + Chr(255) + Chr(255) + Chr(255)
Else
output = output + Chr(0) + Chr(0) + Chr(0) + Chr(1)
End If
output = output + Chr(12) + Chr(2) + Chr(12) + Chr(2) + Mid(raw, 22)

return output;
}

This doesnt include any of the fancier stuff - caching etc.. but that comes later anyway..

Cheers

TD

[neonman]

If you guys are looking for testers on OSX, sign me up. Ive been waiting for a bout a year and a half for a good OSX client, and to play online would be awesome.

[jhurliman]

QUOTE (flat235 @ Sep 15 2003, 12:59 AM)

The prepended chr(99) distinguished this xbox data as "Messenger mode" .. as opposed to other modes...

I need codes for the other modes (chat, wgn) now, thanks.

[flat235]

.. Any chance we can meet up again? I'd love to see how it'd coming on - and I can give you the other details you need then... Rooms mode should be fairly straight forward, but the packet semantics of WGN are absolutely horribly convoluted.. and it can be easy to disrupt the mesh if it doesnt work right

Also, im finishing off server 28 - which includes a few new bits you will need to know about.. I'd like to run the changes past you guys first, so if you notice any horrible mistakes / flaws in it, we can get them sorted before 28 goes to production..

I'll be in the IRC room for most of tonight...

TD

[jhurliman]

Ahh, sorry I meant I need the special prepended character for WGN and Chat mode. Messenger mode prepends a chr(99) to all packets, wgn and messenger mode use...? Right now we're completely focusing on the tunneling code, so no work is currently being done on talking with the XLink server. That's probably a good thing as your protocol is going through a lot of changes right now, so we'll just wait for things to pan out a bit. What we hope to have working soon is a command-line client that can listen for incoming connections, or connect to an IP address of someone using XLink and begin playing. Once we are able to play games and make sure all the packet routing is working, we'll take the tunneling code and plop it into the GUI, where we are implementing all the different gaming modes.

CVS is always frequently updated, and we have cvsweb going too now @ http://xlink.mediali...web.cgi/xlinkd/ for the curious. The code should always compile, but no guarantees you'll get anything other than a segfault until the codebase gets a little less chaotic.

[flat235]

Room = chr(77)
WGN = chr(88)

Just had a brief look over the source.. not fully digested yet, but it look good so far.. One query though.. You seem to be examing ICMP packets which come over the ethernet? The XBox Syslink stack doesnt implement ICMP - or ARP for that matter.. ARP is useless because all the xboxes in syslink all always have the ip address 0.0.0.1, and ICMP simply isnt used...

All we do, on the PCapture side is:

"Is the incoming frame a.) from a 0050F2 mac b.) A UDP frame c.) On port 3074 d.) From IP 0.0.01"

If so, handle it.. if not, totally discard it...

Yes - homebrew xbox apps work a little differently (ARP must be implemented and IP addressing is "normal" ie not all 0.0.0.1), but I would personally leave that till later - as it's easy to snap in..

Thanks,

TD

[jhurliman]

How do you tell if a host isn't up without ICMP? UDP is a connectionless protocol, so you can't just check a socket state to see what's happening. If you know of a better way than looking at ICMP_DEST_UNREACH messages though please let me know, because it's a real pain integrating the ICMP code with the everything else. It's not completely done yet but right now we send out test packets to hosts across the net and add them to our list by default; if any ICMP_DEST_UNREACH messages come back from that host they get dropped.

Also, why are two ports (34518 and 34519) used instead of one? Right now we're implementing all the routing on 34518; where does the other port come in to play?

I would just chat all this over IRC but I won't be here tonight and I'm leaving soon. Hopefully tomorrow will be a free day for me.

[jhurliman]

QUOTE (flat235 @ Sep 15 2003, 12:59 AM)

output = Chr(99) + left(raw, 14) + Mid(raw, 17, 4) + Mid(raw, 25, 2) + Mid(raw, 31, 1) + Mid(raw, 39)

Finally got around to implementing this function... what is the purpose of Mid(raw, 31, 1)? The first byte of the destination address in the IP header? Since this will always be 00 or FF my guess is you are using it to distinguish between broadcast and non-broadcast packets, but isn't that done by looking at the destination MAC?

[neonman]

[flat235]

TD

[jhurliman]

QUOTE (flat235 @ Sep 30 2003, 11:13 PM)

Excellent stuff.. I'll give it a go under MSVC tomorrow at work... Keep it up TD

I'll get .dsp/.dsw files in CVS, otherwise it can be a huge hassle getting the project file setup correctly. You'll also need to install the QT library to compile: http://www.trolltech...qt/noncomm.html

[jhurliman]

I just purchased my own Windows machine, so development on the win32 side has been sped up a bit. I'm still trying to learn how to use this OS and VC++ IDE (it's been a long time) so bear with me. The Libnet-1.1.1 pre-release is out so I was able to compile xlinkd.exe and it appears to be doing something, but this code has never been tested and the hacks to get it working were so ugly I'm holding off committing them to CVS until I do some housekeeping. Anyways if you want to give it a try be my guest; the command line options are xlinkd.exe [-i] interface [-a] address where interface does nothing at this point on win32, it only uses the first interface capable of capturing packets, and address is the remote address you want to connect to. One person runs the program with no options passed, and the other uses -a [other_guys_ip_address] and theoretically you have a tunnel established using the same protocol xlink uses, over port 34518. Some intensive development will be going on in the coming week, so keep posted for updates.

http://xlink.mediali...iles/xlinkd.exe

CVS will be updated when I wake up.

[flat235]

I'll try to allocate some time to testing this today, and I'll repin the topic (dont know how it got unpinned)

Cheers

TD

[flat235]

QUOTE

How do you tell if a host isn't up without ICMP? UDP is a connectionless protocol, so you can't just check a socket state to see what's happening. If you know of a better way than looking at ICMP_DEST_UNREACH messages though please let me know, because it's a real pain integrating the ICMP code with the everything else. It's not completely done yet but right now we send out test packets to hosts across the net and add them to our list by default; if any ICMP_DEST_UNREACH messages come back from that host they get dropped.

Well, to be perfectly honest, the xlink client takes the "totally ignore it" approach.. You see, with the xlink clients, you arent allowed to log in unless the 34518/9 ports are open - it tests them by sending 2 UDP packets from the xserver each time u log in. Hence, if someone shows "online" in xlink, it's guaranteed that any UDP you send will land (well - as close to guaranteed as we need)... Hence, ICMP is completely ignored, and the UDP packets just get piled out to online ppl.. I know, it's not particulary good practice - but we just kept it as simple as possible... no problems seem to have arisen yet with it..

TD