Shawn Hargreaves Blog
Xbox LIVE encrypts all network traffic. This makes it hard for people to cheat by intercepting and modifying packets. However, communication data is required to be sent via an unencrypted channel.
Because of this, each LIVE packet contains two sections. The first part contains encrypted gameplay data, while the second contains unencrypted voice or text chat information.
In the 2.0 XNA Framework, all data sent by your game went in the encrypted part of the packet, while voice was automatically sent unencrypted. Text chat was not permitted, as there was no unencrypted channel available for it.
In 3.0, we are enabling text chat by adding a new SendDataOptions.Chat flag. Here's how this works:
What you should do:
Sorry Shawn, I don;t quite get it.
When you say Text Chat, do you mean like typing messages to each other, Instant Messenger style?
If so then why does this have to be unencrypted? I can't see any reason we couldn't do this already in version 2.
I must be missing something?
However, you did almost touch on another interesting subject when you said that the ordering of chat and non-chat data will be maintained independently. This is similar to the concept of channels in Lidgren, something that would be very useful in XNA studio.
Is there any chance of adding full support for channels in a future release?
> When you say Text Chat, do you mean like typing messages to each other, Instant Messenger style?
> If so then why does this have to be unencrypted? I can't see any reason we couldn't do this already in version 2.
Read the EULA. Technically you could implement this, but if you did, you would be breaking the law.
I think it's great that your team implemented something like this. I recall last year the uproar over that piece of the EULA that forbid text chat (for reasons many programmers don't understand. I do not pretend to be a lawyer or work for MSFT or even know anyone at MSFT, but it seemed to be for legal reasons outside of MSFT's control).
Amazing that you put it in the framework for 3.0. Whether it was just "on your roadmap" or due to the uproar, the demonstration of responsiveness to game programmers' needs is fantastic.
> Read the EULA. Technically you could implement this, but if you did, you would be breaking the law.
Ah ok, me bad.
I also notice that you say that it should only be used for chat and nothing else. However, technically it looks like it could be used as a second independent channel (Lidgren style) so that you could have 2 independent communication streams, each maintaining their own ordering/reliability flags.
So, is the only reason that we shouldn't do that because the unencrypted stream would then be vulnerable to hacking?
> I also notice that you say that it should only be used for chat and nothing else. However, technically it looks like it could be used as a second independent channel
You would be in violation of the EULA if you did this. The only acceptable way to use this stuff is exactly how I outlined in the above post. Please do not abuse this functionality!
Sorry if this comes across as rigid or uncompromising, but that's the way it is. I'm not a lawyer, so I can't go into details as to why these requirements exist, but they do, and we're all responsible for obeying the law...
EULA is not law, btw, it's simply some company's (Microsoft's) policy. It's this sort of thing that keeps anyone serious about development off XNA. Just food for thought.
> EULA is not law
A EULA is a contract between the user and vendor of a product (in this case you and Microsoft). Contracts are a form of law.
> It's this sort of thing that keeps anyone serious about development off XNA.
Huh? Why on earth would the requirement not to encrypt chat data make any difference to developer choices one way or the other?
Also, this requirement is not unique to XNA. All Xbox games are the same way.