Hi
I have been looking at the 2 tank demo's and the netrumble starter kit to try to understand the xna networking magic and seem completely lost with multiple players on the same xbox.

Imagine this simple situation.
PC hosts the game with local player 1up. my xbox connects with 2up and 3up.
Assume the test uses player update packets (netrumble style).

Question 1: is this correct?
When the xbox sends an update packet from 2up. It actually goes to 1up and 3up, but I make the receiving code ignore locally sent packets.


When the host sends a player control packet...

Question 2: Does the update packet go to both players 2up and 3up? or just 2up as he is the first local player on the xbox?

Question 3: Should my receiving code on the xbox (2 players) check both the local players for incoming packets? or just the first local player?

Question 4: If the answer to question 3 is yes then doesn't that mean that the xbox will process the hosts information twice? this doesn't make sense?

Question 5 If the answer to question 3 is no then doesn't that mean that a queue of packets will build up for 3up  that are never read and eventually mess something up?


Took me a few attempts to make sense of what i am asking :)

Sure this is a simple post for anyone thats messed with the networking, any help will be greatly appricated.

1) Right. If you send a packet to everyone in the session (by using the SendData overload that does not have a recipient parameter), this will be delivered to everyone, including other players on the same console. It's entirely up to you whether you filter out and ignore such packets, or if you want to process them in some way (depending on the architecture of your game, it can sometimes be useful to treat local players exactly like remote ones and process all packets identically).

2) Same as #1. The host is not special when it comes to sending packets, so this works the same as for any other player. If you don't specify a recipient when you send the packet, it goes to everyone (except the sender). If you do specify a recipient, it goes to just that player.

3) If you are sure you never send packets to anything but the first player on a box (ie. you always specify a recipient, and this is never the second player), then there would be no need to check that second player for incoming packets. If you do ever send them packets (either explicitly, or implicitly by sending data to everyone) then you do need to check them for packets.

4) If you send to everyone, and there are two players on the same machine, then this machine will get two copies of the packet, yes. It is entirely up to you whether you write your code to process the data twice, or to detect and discard such duplicate data.

5) Yes, if you leave unread packets in the queue, you'll eventually run out of memory.

Shawn,
Are you saying that if I send a packet to everyone, and it goes to a box with two local players, that that box will actually receive the same packet over the wire twice? Or are there smarts at the networking layer that just says "this packet is destined to all players, so please duplicate it on receipt" when sending?

The data is sent over the wire once, then duplicated locally.

Shawn, brilliant answers to all my questions. Big thanks

Jwatte, that was going to be my next question :)  again thanks Shawn

Thought of a question 6 if you have time to answer lads. :)

The examples use different packets for inputs and data updates. Inputs update are the state of the players controller and data updates are the location information of the player etc..

My previous attempts i have made my own c# comms dll to handle packets and built a system based on an old dark basic project, then decided to go xbox with it. I had what I dubbed the PlayerUpdate packet. every client told the server their inputs and position, everytime there was an input change and on a regular beat. The server pretty much echoed out to the other players, then a system of current position and real position was used to determine the distance between the 2, devided by something to give a speed. So the players were moving slightly slower / faster all the time to sync up. More or less the basis of simple system.

so...

Question 6: Why do the examples separate these 2 packets? and not treat them as one packet like i planned to.


Possible answers that i can think of but probably don't fully understand... yet

A. It allows the input data to be effectively cast into a class easy for data encodng and decoding. (serialize and deserialize etc)

B. It allows the receiving side to easily treat the 2 types of packet seperately. i have noticed that a local input packet is read and used whereas a local data packet is binned. I can understand how this reduces code because there is only one place where the input is applied to the player, its not do this locally then send it to the others to on receive, its more like just send it then do it on receive (which will be instant as its local)

C. It allows the 2 packet types to be sent at different frequencies? I have checked the code a few times for this and i am sure they are being sent together all the time. Currently the benefit of possibly sending just one escapes me

D. Its a mistake because of the additional over heads of sending both packets instead of one larger packet. the payload will be same. the demos have been made to be understood easily (well i'm trying) and not network optimised.


Once again any advice and help would be brilliant

Which sample exactly are you talking about?

If you mean the client/server sample, that sends inputs from all client machine to the server, then the server runs all the game logic and sends the resulting game state back to the clients. That's how client/server games work: all the game logic is done on the server, with input data flowing to the server and game state flowing back out from the server.

If you look at the peer-to-peer sample, that works in a different way, doing local logic updates directly on each client, so partial game state (for their locally controlled objects) is sent from each peer to all others.

Some games also use hybrid architectures.

Well, to be really picky, you can still do calculations on the local client to make the local player responsive. As long as you're not breaking the rules, any command you give is going to likely be accepted by the server as well, so you can just go ahead and show the feedback immediately (like, start moving). If it turns out you were wrong, which happens once in a blue moon, then the server will tell you so, and the local player may snap a little bit. Similarly, you can use that mechanism to forward-extrapolate other entities, to attempt to compensate for the lag inherent in network transmission.

The pure model Shawn describes will lead to input latency, where you won't see your guy move in response to a command until the packet has gone to the server and come back. For action games, this may be a problem, hence the latency hiding mechanisms often used. The game is still client/server in this case, though, and it still implements "server authority" (which I think it is that Shawn is trying to convey).

In fact, client/server is more of a networking topology (everyone sends stuff to one node; that node repeats to everybody) than it is an authority designation. You can make each machine responsible for the state of the local entities, and just dump those states to the server, which forward to all other machines, if you want. This is still beneficial, in that each individual client uses less network bandwidth than in the peer-to-peer case -- except for the server, which uses more. Carefully pick your server node based on available bandwidth :-)

I just want to make it really clear that, in general networking speak, "server authority" is something you can implement on top of a "client/server" (or "star") topology, but they are not necessarily one and the same. In fact, to be really clear, it's probably better to talk specifically about "start topology" when that's what you mean, and "server authority" when that's what you mean, and forgo the use of the term "client/server" entirely. But nobody actually does that :-)

the netrumble demo for instance uses one packet for player inputs and another packet for player position info. my question was trying to understand why the demo. (just talking about netrumble now to avoid the confusion I have caused) used these 2 packets instead of one packet that contained both the last player inputs and position. wish to start out with fresh thinking instead going off and making something against the grain that's nasty to fix later lol. the network model is another question all together lol. if you guys don't mind answering more questions I will outline what I intend to do after this query, be very interested to see how it fits.

I'm not especially familiar with the NetRumble code, but my guess is it is using several smaller packets just as an organizational convenience. Just because it calls SendData twice per frame doesn't mean it is sending two actual packets over the wire: the network stack is smart about coalescing such things.

thanking you again :)