Jump to content


Photo

Xbox LIVE being discontinued for Original Xbox consoles and games


  • Please log in to reply
93 replies to this topic

#61 Harcroft

Harcroft

    X-S Enthusiast

  • Members
  • 24 posts

Posted 06 February 2010 - 04:43 PM

QUOTE(CompFreak07 @ Feb 6 2010, 05:20 AM) View Post

InsaneNutter, that would be great if it were also for the Xbox 360!


While people are working on opening up the Xbox1 Emulator to all titles, and homebrew apps. I'm working on getting the CDX installers working on their emulator. So the short answer is "it's in the works".

Also InsaneNutter, AmyGrrl deserves as much credit as I do keeping this DLC archived for the future.

Edited by Harcroft, 06 February 2010 - 04:44 PM.


#62 HotKnife420

HotKnife420

    X-S Freak

  • Members
  • PipPipPipPipPip
  • 1,196 posts

Posted 06 February 2010 - 05:26 PM

QUOTE(GmoneyGrip @ Feb 6 2010, 02:48 PM) View Post

This probably has to do with microshaft's losses here lately. They probably are axing the dead service to the xbox 1 seeing is how its EOL'd. Id say they are losing more money keeping it up than they are making.


Essentially, the view point on this side of the fence is "we were already paying to use our own bandwidth, now we can't". I can see MS looking at the numbers and figuring they were low enough that it could be "not profitable enough".

QUOTE(GmoneyGrip @ Feb 6 2010, 02:48 PM) View Post

Windows 7 isnt even pulling them out of the losses.I think Microshaft is now seeing that it isnt very profitable to be in the console business.With constant RnD to thwart piracy and taking losses on selling equipment that is substandard.I believe there about done with the 360 and if they continue to make consoles expect to see a new xbox announced within 2 years.


Last I heard, the console division was their most profitable one, even after factoring in losses. I'm not sure how much R&D they're throwing at piracy, but I'm sure it's not hurting them that much - if it were, I think they'd just let ixtreme go on live just fine, and take those people's money (cause they'd need it).

QUOTE(GmoneyGrip @ Feb 6 2010, 02:48 PM) View Post

Demos? whats wrong with downloading a demo online and putting it on a disc to play.


You *can* do this, actually (at least, on 360). Simply burn the demo to a disc in the same directory format it would be if you put it on the console's hdd - in the root dir of the CD you would place the 'Content' folder, etc, etc.

#63 Hyper_Eye

Hyper_Eye

    X-S Expert

  • Members
  • PipPipPip
  • 595 posts
  • Gender:Male
  • Location:Huntsvegas, AL.
  • Xbox Version:v1.0
  • 360 version:v5.0 (360S - trinity)

Posted 06 February 2010 - 05:43 PM

QUOTE(Code-Red @ Feb 6 2010, 04:12 AM) View Post

Don't play coy with me Hyper. I've been on this forum just as long as you have, and while I don't have the post count, I do know, for the most part, what the majority of the people on this forum do with their Xboxes.

If you'd like me to go through and do up a little chart of every member in this thread who's alluded to, or talked about 360 piracy in the past to prove my point, would that solve anything? Not really. So don't be "the pot calling the kettle black", telling me I steal games while everyone else here is only here for the emulators and homebrew rolleyes.gif.


Yes I can see very clearly how long you have been here. You would that think that you would be aware by now that on this site you don't accuse someone of piracy. You assume that what people are here for has nothing to do with piracy. A good reason for that is that a lot of people are not here for piracy. It doesn't matter what your conjured statistics say. It also isn't good form to accuse someone of breaking the law without any evidence. It is also still completely beyond the point.

QUOTE(Code-Red @ Feb 6 2010, 04:12 AM) View Post
My point is, is that simply by modifying your Xbox you are violating Microsoft's ToS, plain and simple. Doesn't matter if it's in the comfort of your own home. Coming on here, in this thread, and taking pot shots at MS for shutting down an 8 year online gaming console's network (when the general life expectancy of a console is 5 years max) is what I am addressing.

P.S. My response was mainly in reply to posts like viperware and luthor349's posts.


If people want to mod their console it is their prerogative. If they get banned for it then they know why. If people want to take potshots at MS for this decision that is also their prerogative. It is perfectly reasonable for someone to decide whether or not they will continue to support the Xbox or Xbox Live based on this change. If you think the tone of your post is what they need to change their minds or open their eyes I think you are mistaken.

#64 viperware

viperware

    X-S Young Member

  • Members
  • Pip
  • 30 posts

Posted 06 February 2010 - 06:38 PM

Hey Code Red, did you know you can still play online games on Sony's last gen console? That service doesn't interfere with their new PSN service. Both of which are free. In this case, MS is removing functionality that you pay for from the hardware you bought because they programmed their service poorly. Dev's still make PS2 games and Sony sells 100,00 consoles a month. From a consumer standpoint, based on those trends, the PS2 was a way better value. Based on this history, why would someone get an Xbox360 over a PS3? I would be worried if I bought an Xbox360, my time would be limited even though I pay for my service. On the other hand, I could be rest assured that my PS3 will be playing online games long after the xbox360 is dead. Basically, if this M$ decision upsets a person, it would steer that person right to a PS3. Just seems like a big middle finger to people who are loyal to the Xbox platform.

#65 tweakthings

tweakthings

    X-S Enthusiast

  • Members
  • 19 posts

Posted 06 February 2010 - 08:36 PM

Now people can start modding their original Xbox.

#66 moja

moja

    X-S Young Member

  • Members
  • Pip
  • 59 posts
  • Xbox Version:v1.4
  • 360 version:v4.0 (jasper)

Posted 06 February 2010 - 10:11 PM

QUOTE(viperware @ Feb 6 2010, 06:38 PM) View Post

Hey Code Red, did you know you can still play online games on Sony's last gen console? That service doesn't interfere with their new PSN service. Both of which are free. In this case, MS is removing functionality that you pay for from the hardware you bought because they programmed their service poorly. Dev's still make PS2 games and Sony sells 100,00 consoles a month. From a consumer standpoint, based on those trends, the PS2 was a way better value. Based on this history, why would someone get an Xbox360 over a PS3? I would be worried if I bought an Xbox360, my time would be limited even though I pay for my service. On the other hand, I could be rest assured that my PS3 will be playing online games long after the xbox360 is dead. Basically, if this M$ decision upsets a person, it would steer that person right to a PS3. Just seems like a big middle finger to people who are loyal to the Xbox platform.



You know, that actually does make a lot of sense to me. However, doesn't Sony have an infrastructure in place to network those Playstation (x)'s together? Couldn't they hypotheticaly pull the plug in 20 years when they finally stop making PS2s? Or do the game manufacturers have servers set up? I don't remember how they work.

#67 pookiepoo

pookiepoo

    X-S Senior Member

  • Members
  • PipPip
  • 159 posts
  • Location:SW London
  • Xbox Version:v1.6
  • 360 version:unknown

Posted 06 February 2010 - 10:55 PM

This is the reason that I could never really put my faith in the Xbox. The original and 360 are good but with microsoft in charge its just wrong lol.


Personally I don't see why this should also affect the 360 owners who play originals it makes no sense at all. MS have shown us they they are capable of providing limited access to silver members (which was added to the pre-existing live service when the 360 was released) so why couldn't they just expand the 360 gold service further and leave the original Xbox gold were it was. Like someone said earlier its just laziness (and greed).

You never know they might allow us to play originals again on live... for an extra fee laugh.gif

#68 TMownsu

TMownsu

    X-S Young Member

  • Members
  • Pip
  • 38 posts
  • Location:Fremont California
  • Xbox Version:v1.6b
  • 360 version:v4.0 (jasper)

Posted 06 February 2010 - 11:42 PM

This sucks. How are they going to sell originals? My purchases from Games on demand will be based solely on single player.

#69 gsharpshooter

gsharpshooter

    X-S X-perience

  • Members
  • PipPip
  • 367 posts
  • Xbox Version:unk
  • 360 version:v1 (xenon)

Posted 07 February 2010 - 07:37 AM

Wow I will not hold back any vulgarity on this one, ms fuck u I wish the worst for u now bring back bill gates u stupid pieces of crap so glad I bought a ps3 now the xbox is only good for one thing for me and that is to play homebrew !! This is so stupid like are u dumb shits that retarded that u kill the online for ur old games like really I still play halo 2 and still play splinter cell 1 2 &3 u guys are such thieves man not worth paying $50 any more psn is free and I love that shit fuck xbox back to pc gaming or shall I say a MacBook running a pirated version of ur operating system and ps3.

Edited by gsharpshooter, 07 February 2010 - 07:39 AM.


#70 Kloud

Kloud

    X-S Young Member

  • Members
  • Pip
  • 58 posts

Posted 07 February 2010 - 09:00 AM

QUOTE(moja @ Feb 6 2010, 03:11 PM) View Post

You know, that actually does make a lot of sense to me. However, doesn't Sony have an infrastructure in place to network those Playstation (x)'s together? Couldn't they hypotheticaly pull the plug in 20 years when they finally stop making PS2s? Or do the game manufacturers have servers set up? I don't remember how they work.


They're hosted by the publisher (I'm assuming), considering all of EA's games ended online support when a sequel came out (couldn't pay for all the bandwidth?). Funny, they're still one of the first companies to end support for their games online, even though Microsoft is footing the bill this time around.


#71 GmoneyGrip

GmoneyGrip

    X-S Enthusiast

  • Members
  • 2 posts

Posted 07 February 2010 - 04:48 PM

any game not hosted by you will inevitably be unplayable some day.You can pay for 3rd party hosting as long as they offer it as availability.

Some games never lose online appeal like unreal tourney 1/2/3/4 whatever forms friendships and possibly clans and what not.Some still are going strong alot of forums for unreal tournament 1 are up still on the net.

Not to your choice though if you have purchased such a game for the xbox 1 then your journey ends as it will with all console games as long as privatized servers are supported by the public.

Its time for revolution in the console business these guys are dictating what services you can have.Like i said b4 look at xbox media extender its basic and doesnt fully intigrate with windows.You could in theory stream your netflix account from the extender to windows but they want you to pay for that as a added expense when you already have it and from the same company.

Microsoft is ruining the gaming scene as well they get titles a month ahead of sony and secure platform only titles(sony did at one time as well).

What id like to see in a console:

1. universal service for gaming whether its PS,PC or xbox or whatever they connect openly to servers available(gamespy,dedicated,local).

2.UNIVERSAL discs that run on ALL platfoms. There is no need for extra plastic laying around for multiple platforms.This solves a # of problems.

3. Internet capability with all the plugins for netflix or whatever you want to load.With a option for KB/mouse
to make life easier for web surfing and all the plugins for viewable content.

4. the ability to run a os.Consoles are fairly portable all you need is a tv and you could take it with you anywhere write papers print ,surf the net,messenger,voip,netflix whatever.

This is why my xbox which was given to me sets in the corner disassembled.Untill i can play games online without having to pay for something thats a given elsewhere its a useless piece of hardware for me.All the games i want to play are also on PC i can play better than the xbox.For the price you pay for live service a year you could update cpu components.$60 video cards trounce the performace of the xbox 360 already.4-5
years of live service alone will fully upgrade your pc.That to me is a unacceptable expense where you get less in the end.

Quit feeding the monkeys.Thier not your friend they will take your arm off with the bananna and beat you with it and you just keep smiling.





#72 pookiepoo

pookiepoo

    X-S Senior Member

  • Members
  • PipPip
  • 159 posts
  • Location:SW London
  • Xbox Version:v1.6
  • 360 version:unknown

Posted 07 February 2010 - 07:17 PM

QUOTE(GmoneyGrip @ Feb 7 2010, 03:48 PM) View Post

any game not hosted by you will inevitably be unplayable some day.You can pay for 3rd party hosting as long as they offer it as availability.

Some games never lose online appeal like unreal tourney 1/2/3/4 whatever forms friendships and possibly clans and what not.Some still are going strong alot of forums for unreal tournament 1 are up still on the net.

Not to your choice though if you have purchased such a game for the xbox 1 then your journey ends as it will with all console games as long as privatized servers are supported by the public.

Its time for revolution in the console business these guys are dictating what services you can have.Like i said b4 look at xbox media extender its basic and doesnt fully intigrate with windows.You could in theory stream your netflix account from the extender to windows but they want you to pay for that as a added expense when you already have it and from the same company.

Microsoft is ruining the gaming scene as well they get titles a month ahead of sony and secure platform only titles(sony did at one time as well).

What id like to see in a console:

1. universal service for gaming whether its PS,PC or xbox or whatever they connect openly to servers available(gamespy,dedicated,local).

2.UNIVERSAL discs that run on ALL platfoms. There is no need for extra plastic laying around for multiple platforms.This solves a # of problems.

3. Internet capability with all the plugins for netflix or whatever you want to load.With a option for KB/mouse
to make life easier for web surfing and all the plugins for viewable content.

4. the ability to run a os.Consoles are fairly portable all you need is a tv and you could take it with you anywhere write papers print ,surf the net,messenger,voip,netflix whatever.

This is why my xbox which was given to me sets in the corner disassembled.Untill i can play games online without having to pay for something thats a given elsewhere its a useless piece of hardware for me.All the games i want to play are also on PC i can play better than the xbox.For the price you pay for live service a year you could update cpu components.$60 video cards trounce the performace of the xbox 360 already.4-5
years of live service alone will fully upgrade your pc.That to me is a unacceptable expense where you get less in the end.

Quit feeding the monkeys.Thier not your friend they will take your arm off with the bananna and beat you with it and you just keep smiling.


I know you said you don't like live but just to clear something up... (from my understanding) XBL does not have private/dedicated servers, it operates via a P2P system. So in essence MS are charging its live customers to use their own connections and not "Privatised Servers".

#73 luther349

luther349

    X-S Hacker

  • Members
  • PipPipPipPipPipPip
  • 2,369 posts
  • Location:irvine ky
  • Xbox Version:v1.0
  • 360 version:v1 (xenon)

Posted 08 February 2010 - 05:47 AM

i dunno the details between xbox live and 360 live. but removing legacy support from 360 live pretty much slams the door on hacking live with the original sdk. the original xbox sdk was leaked a doesn't and a half times and no live hacks ever happened.

but the issue isnt with the servers anyways. its the games. even if we got the sdk we would somehow need to change all the games to connect to the new dns. as you said they probably still use the same dns they did back then.

Edited by luther349, 08 February 2010 - 05:50 AM.


#74 antiflag1980

antiflag1980

    X-S X-perience

  • Members
  • PipPip
  • 399 posts
  • Location:Cincinnati, OH
  • Xbox Version:v1.0

Posted 08 February 2010 - 07:26 AM

QUOTE(luther349 @ Feb 8 2010, 12:47 AM) View Post

i dunno the details between xbox live and 360 live. but removing legacy support from 360 live pretty much slams the door on hacking live with the original sdk. the original xbox sdk was leaked a doesn't and a half times and no live hacks ever happened.

but the issue isnt with the servers anyways. its the games. even if we got the sdk we would somehow need to change all the games to connect to the new dns. as you said they probably still use the same dns they did back then.

I would think the programming for where it connects would be built into the live dashboard or bios or eeprom, not games right? Dashboard would make the most sense to me seeing as how they could update it? Then again the xbox didn't multitask so once you launched a game it used the games settings right? Anyone know the answer to this?

Edited by antiflag1980, 08 February 2010 - 07:27 AM.


#75 _zlinky

_zlinky

    X-S Member

  • Members
  • Pip
  • 75 posts

Posted 08 February 2010 - 08:31 AM

QUOTE(antiflag1980 @ Feb 8 2010, 01:26 AM) View Post

I would think the programming for where it connects would be built into the live dashboard or bios or eeprom, not games right? Dashboard would make the most sense to me seeing as how they could update it? Then again the xbox didn't multitask so once you launched a game it used the games settings right? Anyone know the answer to this?


That would probably be true for the 360, but the Xbox1 operated differently. The code used to access Xbox Live was done in the XOnline library (which is statically linked to the xbe). I'm assuming luther is right about the dns being static/unique and that might be a challenge altogether to circumvent.

Although I'm not proficient in how Xbox Live works on a software level, I do plan on reading up on what the XDK says about it and see what else I can discover. After reading the XDK for a while, this is what it has to say about the Xbox Live security measures of the XOnline library:

QUOTE

Network security is paramount to the success of multiplayer games. A single effective exploit of a game can affect thousands of players. As network gaming becomes more common, the stakes get higher. The number of players willing to cheat increases, and the threat of cheating becomes a critical factor in game design. The creators of the Xbox video game system from Microsoft take these issues very seriously. Secure communication is one of the foundations of the Xbox.

The Xbox Security Network Library (SNL) handles all Xbox communication, whether that communication is Xbox to Xbox or Xbox to server. The Xbox SNL is based on the Winsock API, with one very important difference: it's cryptographically secured. Packets are encrypted and stamped with authenticating hash values. When an Xbox receives a packet, the packet can be verified against the hash value. If any data has been changed in transit, the packet will fail authentication and will be thrown away. This solves the issues of packet tampering at a very low level. Games themselves don't need to support any additional mechanism for preventing these types of game cheats.

Converting existing Winsock code to use the Xbox Security Network Library is a matter of calling some new initialization functions and establishing a secure connection. Once a connection has been established, the standard Winsock calls apply.

The code snippets below are based on the WinsockPeer sample in the Xbox SDK, a simple peer-to-peer Xbox game. See the WinsockPeer code for the full implementation of the concepts shown. In the code examples, error checking has been removed for clarity. Your game should check for and handle errors appropriately.

Checking the Xbox Connection Status
Xbox titles must allow the player to play a network multiplayer game only when the Xbox is physically connected to another Xbox via an Xbox System Link Cable or connected to a hub. A title can detect a valid physical connection by calling XNetGetEthernetLinkStatus. This function can be safely invoked prior to calling any network initialization routines. If the function returns zero, the Xbox is not connected. Otherwise the Xbox is connected, and additional information about the connection is provided in the return value.

BOOL IsXboxConnected()
{
DWORD dwStatus = XNetGetEthernetLinkStatus();
return( dwStatus != 0 );
}

To meet Xbox Technical Certification Requirements (TCRs), the connection status must be checked in the main game loop at least once per second, and the game must display appropriate UI informing the player that the network cable was disconnected. XNetGetEthernetLinkStatus is very fast, on the order of three to four microseconds.

Initializing the Xbox Network Library
Once the connection status has been verified, the game can initialize the Xbox SNL. There are two initialization routines required: XNetStartup and the standard Winsock WSAStartup. For the default Xbox SNL parameters, call XNetStartup with NULL.

// Default Xbox SNL initialization
INT err = XNetStartup( NULL );

To customize the parameters, use the XNetStartupParams structure. Set the first field to the size of the structure (used for versioning). To obtain a default parameter, set that parameter to zero. The default settings are documented in the Winsockx.h header file.

// Change receive buffer size to 32 K (default is 16 K)
// All other parameters will be set to default values
XNetStartupParams xnsp;
ZeroMemory( &xnsp, sizeof(xnsp) );
xnsp.cfgSizeOfStruct = sizeof(xnsp);
xnsp.cfgSockDefaultRecvBufsizeInK = 32;
INT err = XNetStartup( &xnsp );

Once the Xbox SNL has been successfully initialized, call WSAStartup to do the standard Winsock initialization. The Xbox allows all versions of Winsock up through 2.2 (that is, 1.0, 1.1, 2.0, 2.1, and 2.2), although it technically supports only and exactly what is specified in the Xbox network documentation, not necessarily the Winsock functional specification.

// Init Winsock
WSADATA wsaData;
INT err = WSAStartup( MAKEWORD(2,2), &wsaData );

The network library can be shut down and removed from memory by calling WSACleanup and then XNetCleanup.

System Link Play
Xbox system link play is in effect when any of the following are true:

An Xbox is directly connected to another Xbox using the system link cable. A system link cable is simply an Ethernet crossover cable.
An Xbox is connected to an Ethernet hub (bridge) with an Ethernet cable. To meet TCRs, a maximum of 16 Xbox consoles can communicate with each other via a hub.
An Xbox is connected to a local area network (LAN). Up to 16 Xbox consoles on the same subnet can communicate with each other. The Xbox does not support communication across different subnets. The Xbox does not officially support LAN play. In other words, LAN play will work for many players (those on the same subnet), but not necessarily all players (those on different subnets).
In general, system link play describes an Xbox that is "connected" but not on the Internet. Because games running in system link mode don't have access to any external servers, including DNS or Xbox servers, they must advertise and discover their own game sessions. The following sections describe how games can support system link play. Many of these techniques will also apply to Internet games, but this paper focuses specifically on system link play.

Finding a Game
Once a game has verified its connection status and initialized the SNL, it can discover if any Xbox consoles are hosting game sessions. With system link play, there are no external servers that track game sessions, so the only way to discover active game sessions is to send a message to all connected Xbox consoles via an Ethernet broadcast.

To create a broadcast socket, create a UDP socket and set the SO_BROADCAST option. The following code creates a broadcast socket.

// Create UDP socket
SOCKET sBrd = socket( AF_INET, SOCK_DGRAM, IPPROTO_UDP );

// Set broadcast option
BOOL bBroadcast = TRUE;
INT err = setsockopt( sBrd, SOL_SOCKET, SO_BROADCAST,
(const char*)&bBroadcast,
sizeof( bBroadcast ) );

Use this socket to broadcast a game discovery message. This message can contain any useful information about the requesting client, but it will typically have only two important pieces of data:

A message ID. If multiple types of messages are issued on the same port, the message ID is used to distinguish the message payloads. If the only messages issued on a given port are game discovery messages, then the port itself is the identifier and the message ID is not required.
A nonce used to uniquely identify the client. A nonce is a random number used for a single transaction. When an active game session is discovered, the host cannot reply directly to us, because we don't have a secure channel established yet. The host must instead broadcast a response to all connected Xbox consoles. To distinguish between our game discovery request and other requests, the host replies with the same nonce that it received. Use a nonce of at least 8 bytes to minimize the chance of duplicates.
// Game discovery message payload
struct FindGame
{
BYTE ID;
BYTE Nonce[8];
};

The Xbox API includes a function that can be used to generate nonces called XNetRandom. For details on this function, see the section entitled Random Number Generation.

// Generate nonce and fill out discovery message payload
FindGame findGame;
findGame.ID = MSG_FIND_GAME;
INT err = XNetRandom( findGame.Nonce, sizeof(findGame.Nonce) );

Now the game discovery request can be issued by broadcasting the message to all connected Xbox consoles.

The following code shows how to issue a broadcast game discovery message. Use the broadcast socket created above. The port number you choose for broadcast messages is entirely up to the game. Any port number in the range 1 through 65535 is valid.


// Create broadcast address
SOCKADDR_IN saSendTo;
saSendTo.sin_family = AF_INET;
saSendTo.sin_addr.s_addr = INADDR_BROADCAST;
saSendTo.sin_port = htons( GAME_BROADCAST_PORT );

// Broadcast the message to all system link Xbox consoles
INT err = sendto( sBrd, (const char*)(&findGame),
sizeof(findGame), 0,
(const sockaddr*)(&saSendTo),
sizeof(SOCKADDR_IN) );

The discovery phase must last no longer than three seconds (a system link TCR). If no responses have been received within that time, no game hosts are available and the title should display an appropriate message.

If a response is received, it will contain information about the game host that will allow a secure connection to be established. Multiple responses may be received, indicating that there are multiple game hosts on the network. The Xbox SNL ensures that a title will only send messages to and receive messages from other Xbox consoles running the same game. Details about the host response are given in the next section.

Hosting a Game
Hosting a game requires the same networking startup sequence as described above. To host a game, a title must additionally acquire its Xbox address and create a session key that uniquely identifies the game.

An Xbox address is called an XNADDR. The XNADDR structure contains the information required to completely and uniquely identify any Xbox on either a system link network or on the Internet, even if that Xbox is communicating through network address translation (NAT). The component of the XNADDR structure used by system link play is the Ethernet media access control (MAC) address of the Xbox.

To acquire the Xbox address, call XNetGetTitleXnAddr. This call is asynchronous, because it requires a few seconds to acquire the IP address. When linking with the current version of the secure library (XNETS.LIB), this call is synchronous, because it only acquires the Ethernet MAC address, but in future online releases, this function will also acquire the IP address, so it's important to check the return value and handle the XNET_GET_XNADDR_PENDING condition.

XNADDR xnHostAddr;
DWORD dwStatus;
do
{
// Repeat while pending; OK to do other work in this loop
dwStatus = XNetGetTitleXnAddr( &xnHostAddr );
} while( dwStatus == XNET_GET_XNADDR_PENDING );

// Error checking
if( dwStatus == XNET_GET_XNADDR_NONE )
return FALSE;

To create a session identifier, call XNetCreateKey and XNetRegisterKey. The XNetCreateKey function generates an XNKID/XNKEY pair by filling both structures with random numbers. See the section Random Number Generation for more details. The XNetRegisterKey function informs the network stack to "listen" for incoming requests from other Xbox consoles that are using the same session key.

XNKID xnHostKeyID;
XNKEY xnHostKey;
INT err = XNetCreateKey( &xnHostKeyID, &xnHostKey );
err = XNetRegisterKey( &xnHostKeyID, &xnHostKey );

When a game session is finished, call XNetUnregisterKey to stop accepting packets from any Xbox that is using the matching XNKID/XNKEY session.

Once the title has acquired its Xbox address and has registered a session, it's ready to accept game discovery messages and reply with information about the game. The following code creates a socket that listens for broadcast messages.

// Create UDP socket
SOCKET sLBrd = socket( AF_INET, SOCK_DGRAM, IPPROTO_UDP );

// Bind to INADDR_ANY
SOCKADDR_IN sa;
sa.sin_family = AF_INET;
sa.sin_addr.s_addr = INADDR_ANY;
sa.sin_port = htons( GAME_BROADCAST_PORT );
INT err = bind( sLBrd, (const sockaddr*)( &sa ),
sizeof( SOCKADDR_IN ) );

// Make socket non-blocking
DWORD dwNonBlocking = 1;
err = ioctlsocket( sLBrd, FIONBIO, &dwNonBlocking );

In the main game loop, check to see if any game discovery messages have been sent from other Xbox consoles.

// See if any game discovery broadcasts have been received
FindGame findGame;
INT iBytes = recv( sLBrd, (char*)(&findGame),
sizeof(findGame), 0 );
if( iBytes != SOCKET_ERROR && iBytes == sizeof(findGame) )
{
if( findGame.ID == MSG_FIND_GAME )
// reply with "game found" message
}

Game clients need four important pieces of information to verify the discovery message, display useful information about the session, and establish a secure connection to the game host:

The nonce received from the client must be sent back so that the client can verify that this response is meant for him. A secure connection between the host and the client hasn't been established yet, so the host must reply with a broadcast message. In order to distinguish the message, the client must compare the nonce it generated with the nonce it receives back from the host. If the nonces match, the message was meant for the client. If not, the client must ignore the message, because it was meant for a different Xbox console.
The session name. If the client displays this name in the list of sessions that can be joined, the session name must be broadcast. The name must be a non-technical descriptive name for the session (system link TCR).
The XNKID/XNKEY pair of the host session. This data will enable a secure session to be established between the host and the client.
The XNADDR of the host. This address will allow messages to be sent directly to the host rather than broadcast to all Xbox consoles.
// Game found message payload
struct GameFound
{
BYTE ID; // message ID
WCHAR GameName[32]; // generated by host
BYTE Nonce[8]; // copy of nonce from client
XNKID KeyID; // from XNetCreateKey()
XNKEY Key; // from XNetCreateKey()
XNADDR HostAddr; // from XNetGetTitleXnAddr()
};

// Fill out game found message
GameFound gameFound;
gameFound.ID = MSG_GAME_FOUND;
lstrcpynW( gameFound.GameName, gameName, 32 );
CopyMemory( gameFound.Nonce, findGame.Nonce, 8 ); // from client
CopyMemory( &gameFound.KeyID, &xnHostKeyID, sizeof(XNKID) );
CopyMemory( &gameFound.Key, &xnHostKey, sizeof(XNKEY) );
CopyMemory( &gameFound.HostAddr, &xnHostAddr, sizeof(XNADDR) );

The following code shows a typical response by the host to a game discovery message. This message is sent using the same style of broadcast socket that the client used to send the discovery message. Broadcast messages are always encrypted.

// Create broadcast address using INADDR_BROADCAST
SOCKADDR_IN saSendTo;
saSendTo.sin_family = AF_INET;
saSendTo.sin_addr.s_addr = INADDR_BROADCAST;
saSendTo.sin_port = htons( GAME_BROADCAST_PORT );

// Broadcast the message to all system link Xbox consoles
INT err = sendto( sBrd, (const char*)(&gameFound),
sizeof(gameFound), 0,
(const sockaddr*)(&saSendTo),
sizeof(SOCKADDR_IN));

Depending on the type of game, additional information could well be included in this message, including the name of the hosting player, the number of players currently in the game, and game statistics.

Connecting to a Game
The client that issued the discovery request can wait up to three seconds to get the list of available hosts (system link TCR). The discovery response is received using the same style of listening socket that the host used when listening for discovery messages. Ignore messages with non-matching nonces, because they are intended for other Xbox consoles that are running the same game and also happen to be in game discovery mode.

// See if any hosts have responded to game discovery
GameFound gameFound;
INT iBytes = recv( sLBrd, (char*)(&gameFound),
sizeof(gameFound), 0 );
if( iBytes != SOCKET_ERROR && iBytes == sizeof(gameFound) )
{
if( gameFound.ID == MSG_GAME_FOUND &&
memcmp( &gameFound.Nonce, findGame.Nonce, 8 ) == 0 )
{
// add the session info to the list of sessions
}
}

Depending on the type of game and the number of sessions, a title may automatically select a session or present the list of sessions and allow the player to choose. Once a session has been selected, the client must register the game's session keys and translate the host XNADDR to an Internet address (IN_ADDR) that can be used to communicate directly with the host. The XNetRegisterKey function informs the network stack to "listen" for incoming messages from other Xbox consoles that are using the same session key.

INT err = XNetRegisterKey( &gameFound.KeyID, &gameFound.Key );

The XNetXnAddrToInAddr function converts an Xbox XNADDR to an IP address that is usable by Winsock to communicate directly with that Xbox. The translation requires the session key ID. Be aware that this IN_ADDR is not a "real" IP address. It has the format 0.x.y.z. If an IN_ADDR is transmitted to another Xbox or a PC, the target Xbox/PC cannot use the IN_ADDR, because it is useful only in the context of the Xbox that converted the address. One way to think of the IN_ADDR is as a "handle" to the actual XNADDR. The Xbox SNL knows how to convert this handle into the XNADDR.

IN_ADDR inHost;
INT err = XNetXnAddrToInAddr ( &gameFound.HostAddr,
&gameFound.KeyID, &inHost );

Now both the host and the client have registered the same session key and the client knows the host's unique Xbox address. Now the client can send messages directly to the host. No more broadcast messages are required. The port number you choose for non-broadcast messages is entirely up to the game. Any port number in the range 1 through 65535 is valid. Here's an example of how the client might issue a "join game" message to the host.

struct JoinGame
{
BYTE ID; // message ID
WCHAR PlayerName[32]; // name of player that wants to join
};

// Generate the message payload
JoinGame joinGame;
joinGame.ID = MSG_JOIN_GAME;
lstrcpynW( joinGame.PlayerName, playerName, 32 );

// Talk directly with the host
SOCKADDR_IN saSendTo;
saSendTo.sin_family = AF_INET;
saSendTo.sin_addr = inHost; // from XNetXnAddrToInAddr
saSendTo.sin_port = htons( GAME_DIRECT_PORT );

// Send message directly to host
INT err = sendto( s, (const char*)(&joinGame),
sizeof(joinGame), 0,
(const sockaddr*)(&saSendTo),
sizeof(SOCKADDR_IN));

From this point on, all messages sent between the player and the host can be sent using standard socket calls. The Xbox SNL automatically handles the underlying key exchanges, authentication and encryption of the messages. Any message that has been tampered with or is otherwise bogus will be detected and ignored by the Secure Network Library and will never be propagated to the game.

Allowing Players To Join
When the host game is allowing players to join, it must listen for join messages. Join messages are sent directly from a client Xbox to the host Xbox, so the host Xbox can determine where the message originated. This allows the host to determine the XNADDR of the client. In the game loop, check to see if any join messages have been sent from other Xbox consoles. Note the use of recvfrom to determine the source of the message.

// See if any game join requests have been received.
// Socket s has been bound to INADDR_ANY, GAME_DIRECT_PORT.
JoinGame joinGame;
SOCKADDR_IN saFrom;
INT iSize = sizeof( SOCKADDR_IN );
INT iBytes = recvfrom( s, (char*)(&joinGame), sizeof(joinGame),
0, (sockaddr*)(&saFrom), &iSize );
if( iBytes != SOCKET_ERROR && iBytes == sizeof(joinGame) )
{
if( joinGame.ID == MSG_JOIN_GAME )
// handle join game message (see below)
}

At this point, we have a valid "join game" message and we have some information about the Xbox who sent the message. Specifically, we have the IN_ADDR of the source Xbox. Again, this IP address is not a "real" IP address. The host can continue to use this IN_ADDR to communicate with the client Xbox for the duration of the session, but if the host wants to send this Xbox address to other Xbox consoles, the IN_ADDR must be translated to an XNADDR. To translate an IN_ADDR to an XNADDR, use XNetInAddrToXnAddr. The last parameter of the function is the optional XNKID that can be used to retrieve the session key ID associated with the address. In this case, the host already knows the session key ID, so we pass NULL.

XNADDR xnClient;
INT err = XNetInAddrToXnAddr( saFrom.sin_addr, &xnClient, NULL );

It's up to the title to decide how to handle join requests. If the game is already full, it will most likely issue a "join failed" response. If the join is allowed, the game will respond with a "join approved" message. It may also send additional information about the game and other players in the game.

Distributing Xbox Addresses
System link games can choose whatever policy they wish when it comes to player communication. The host can act as the server and all communication can happen between the host and each player (client-server model), or the host can distribute the addresses of all of the Xbox consoles participating in the game and each player can communicate directly with the other players (peer-to-peer model).

To distribute Xbox addresses, the host typically sends the XNADDR of each existing player when a new player joins the game. After that, whenever a new player joins, the host sends the XNADDR of the new player to each existing player.

When a game receives notification of a new player XNADDR, it translates the XNADDR to an IN_ADDR using XNetXnAddrToInAddr and the game session key ID (XNKID). After the translation, the title can throw away the XNADDR (unless it intends to forward the address to another Xbox) and use the IN_ADDR for all future communication.

Never send an IN_ADDR on the wire, because it is useless outside of the Xbox that owns it. Each Xbox must do its own translation of XNADDRs to IN_ADDRs, because each Xbox network stack has its own local table of XNADDRs / IN_ADDRs.

Handling Player Disconnects
Game developers that write networked PC games often assume that the way a player leaves a networked game is via the UI, which typically invokes a standard termination of sockets (for example, shutdown, closesocket, or WSACleanup).

On the Xbox, the ways a player will commonly leave a networked game are by turning off the Xbox or rebooting into a different game. Therefore a game should never rely on a socket getting closed to indicate that a player has left the game.

There are two common methods for detecting when a player has left or a connection has been dropped. One way is to periodically send the other players an "are you there?" message (ping) and see if they respond. Another method is for every player to periodically broadcast an "I'm here" message (heartbeat). Each player keeps track of the other player's heartbeats, and when players don't hear a heartbeat in a fixed period of time, they assume that player left. The WinsockPeer sample in the Xbox SDK uses the heartbeat method, sending heartbeats three times per second and timing out players who haven't sent a heartbeat for two or more seconds.

UDP vs. TCP
The Xbox SNL supports both UDP and TCP protocols. Both protocols are always authenticated and encrypted. UDP is a connectionless, unreliable protocol. UDP packets may arrive out of order, and they may never arrive at all. UDP packets are smaller than TCP packets and generally exhibit better performance. Broadcast messages by definition require UDP. TCP is a connection-oriented, reliable protocol. TCP packets are re-sent if they cannot be delivered and are guaranteed to arrive in the order they were sent. TCP packets are larger than UDP packets.

For system link play, it's uncommon to see UDP packet loss or packet out-of-order issues. UDP is also a better protocol choice for performance reasons. Most multiplayer games choose UDP for these reasons, and many games create their own "reliable UDP" protocols on top of UDP. If performance is not an essential game requirement but reliable packets are key, choose TCP.

XNet Library Versions
There are four different versions of the Xbox SNL library, described below. In general, development work will take place using XNET.LIB or XNETD.LIB, and shipping titles will use XNETS.LIB.

XNET and XNETD Developer Libraries
XNETD version includes debugging information, assertions, symbols, and so on. XNET version does not have debugging enabled.
Use these libraries for games in development.
Allows remote debugging of the game.
Allows communication with PCs and other untrusted hosts if XNET_STARTUP_BYPASS_SECURITY is specified in XNetStartup.
Enables unencrypted packets if XNET_STARTUP_BYPASS_ENCRYPTION is specified in XNetStartup.
XNetGetDebugXnAddr returns the debugger IP address in the ina field of the XNADDR.
XNetGetTitleXnAddr returns the title IP address in the ina field of the XNADDR.
XNETSD Secure Library
Includes debugging information, assertions, symbols, and so on.
Use this library for final debugging stages of game or security testing.
Allows remote debugging of the game.
Does not allow communication with untrusted machines, with the exception of the debugger, even if XNET_STARTUP_BYPASS_SECURITY is specified in XNetStartup.
Always transmits encrypted packets, even if XNET_STARTUP_BYPASS_ENCRYPTION is specified in XNetStartup.
XNetGetDebugXnAddr returns the debugger IP address in the ina field of the XNADDR.
The ina field of the XNADDR returned by XNetGetTitleXnAddr is empty.
XNETS Secure Libraries
Use this library for shipping titles. Titles must link with this library to pass system link TCRs.
Does not allow remote debugging; must use hard disk logging or other methods for debugging.
Does not allow communication with PCs, even if XNET_STARTUP_BYPASS_SECURITY is specified in XNetStartup.
Always transmits encrypted packets, even if XNET_STARTUP_BYPASS_ENCRYPTION is specified in XNetStartup.
XNetGetDebugXnAddr returns XNET_GET_XNADDR_NONE.
The ina field of the XNADDR returned by XNetGetTitleXnAddr is empty.
Communicating with Development Systems
By default, an Xbox console may communicate with another Xbox console only using secure communication. All versions of the XNet libraries support secure communication between Xbox consoles. However, if you are linking with the XNet developer libraries (either XNETD.LIB or XNET.LIB), you can also communicate with "untrusted" devices, including PC development systems. To enable communication to untrusted hosts, set the XNET_STARTUP_BYPASS_SECURITY parameter when calling XNetStartup.

XNetStartupParams xnsp;
ZeroMemory( &xnsp, sizeof(xnsp) );
xnsp.cfgSizeOfStruct = sizeof(xnsp);
xnsp.cfgFlags = XNET_STARTUP_BYPASS_SECURITY;
INT err = XNetStartup( &xnsp );

On Xbox development systems, the Xbox IP address is available on the main menu of the XDK Launcher. There are two IP addresses, because the Xbox has two network stacks. You can toggle through the addresses by pressing the Black button on the controller. The "D" address is the address of the debug stack. The debug stack is used by XBDM for remote debugging. Microsoft® Visual Studio® uses this IP address to communicate with the Xbox during remote debugging. The "T" address is the address of the title stack. The title stack is used by games for game networking. The Xbox title IP address can be retrieved programmatically by games linked with the developer library by accessing the XNADDR ina field from the XNADDR returned by XNetGetTitleXnAddr. The debug address can be similarly found using XNetGetDebugXnAddr.

From the PC side, an application may call DmGetAltAddress to retrieve the title IP address for the Xbox. For more details, see the Debugger API section in the Xbox Development Kit documentation.

The code shown above will compile and link successfully with the Xbox secure libraries (XNETS.LIB and XNETSD.LIB), but the XNET_STARTUP_BYPASS_SECURITY parameter will be ignored, and connections to untrusted hosts will fail. The ina field of the XNADDR returned by XNetGetTitleXnAddr will also be empty.

When linking with XNETSD.LIB, the debugging version of the secure library, only XBDM (debugger) communication is allowed to untrusted hosts. In other words, XNetGetDebugXnAddr will return the IP address of the debug stack when linking with XNETSD.LIB, but XNetGetTitleXnAddr will not return a valid IP address when linking with either XNETSD.LIB or XNETS.LIB.

Random Number Generation
For maximum security, use the XNetRandom function whenever you need to generate nonces or other random data sent on the wire. All random keys (including XNKID/XNKEY pairs), nonces, and encryption initialization vectors created by the Xbox SNL are generated using this function. XNetRandom uses an algorithm for generating random bits based on RFC 1750 (Randomness Recommendations for Security; see http://www.faqs.org/rfcs/rfc1750.html). Randomness is not based on predictable pseudo-random mathematical number generators. Instead, randomness is generated using a combination of random input sources, including physical sources of entropy such as hard disk seek time. This technique creates cryptographically strong random bits that prevent an adversary from guessing keys, nonces, or other generated values.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users