Gotcha #1 - Broadcast doesn't get recieved locally

Networking & Multiplayer
#1

Thought it might be useful to note things that catch you out - probably due to my own stupidity but heh.

The first one that got me spending a bit of time was broadcasting to channels. When you’re writing a chat server your clients sends some text to the server, which the server then spits out to all connected users (including the one that originally sent it). This makes some sense for chat because most of the time you’d like to see your chat message appear after you’ve sent it - and hence sending it back to the originator is convienient.

However, when you’ve got game data you’re normally keeping a local copy which you’re telling everyone else about. In my case, each client maintains their own local tank so they don’t want to be told about network updates to it since they’re probably out of date. When this type of client sends an update to the server its sent to everyone accept the originator.

When you send a broadcast in SGS you get the second effect. However, since the first thing I implemented was chat (seemed like a quick reasonable test) I expected it to send me back my data - took me a while to realise (i.e. check the javadoc) why I wasn’t getting any messages back :slight_smile:

Kev

#2

Its like that with IRC, too. You dont get the message back. It would introduce lots of weird lag. As a side effect the messages may arrive in a different order on each client.

#3

I have to admit this was a call I made based on my preferences.

From my perspective, a local echo is easy, having to filter my own messages out al lthe tiem so I dont respond to myself is a pain in the butt 8)

But Ill make a note to call that out in the Javadoc, thanks!

#4

Not receiving your own messages through I/O is pure evil. (that’s a tiny bit worse than a pain in the butt.)

Everybody should see all messages in the same order, otherwise it will get confusing, or annoying, as for example you don’t know whether or not the chat actually works (server lag/hickup - player types a monologue - wonders why everybody is so silent)

#5

Hmm. I really dont see the issue. There is no functional difference between:
synchronized {
sendToOthers
echoToMe
}

as

sendToAll

since its all happening in parallel on everyones machiens you have no gaurantee of inter-machine order anyway!

The aft of the matter is that the B version is just A with the echo lower down in the code.

#6

I don’t necessarily agree. In a case where you send to all through the server, the server can make arrangements to serialize messages in a specific order between different objects. In the local case, you can’t make that decision – echoToMe will likely make you see the message much sooner than a message that “at the same time” is queued from the server. Also, you don’t always have all the state on the client that you need to re-sort the messages in the same order as you’d see them from the server.

Therefore, the ability to echo things back to yourself from the server is sometimes useful.

The classic example is an input-synchronous RTS, but there are other cases where this structure makes sense, too. Of course, you can still implement that without explicit support, but it’s more cumbersome than if there were support (duh :slight_smile:

#7

I think you need to distinguish between channel connection and server side logic (GLO stuff.)

We are talkign here purely about the channels, where I am pretty sure what I said is 100% true.
If you are organizing through server side logic then you DONT want echo because ist all going unicast to the server who is organizing it and sending it out.

If a client is acting a server (something I wouldnt do in a Darkstar app) then you need to send it all unciast to the server-client who is going to organize it and send it out. In which case a simple syncornize in your server-client code makes it atomic as I showed above.

Maybe Im missign something but I really don’t see the issue.

#8

I misunderstood your ‘echo’, thinking it was a local echo (like IRC).

Although I’d prefer a send-to-all, the current solution isn’t that bad.

#9

Just to summarize:

There is a difference between messages for Chat and for unit Updates.

  • You dont want your own unit updates.

  • But you do want your own Chat messages to go to the server and come back. From a programmers perspective you dont want that either. But from a players perspective they send a chat message and if it doesnt appear on the screen quickly, its a simple test of lag. Then the player can adjust what he is doing in the game based on how bad it is. This is how WOW and some other games work.

In Wow you can move around anywhere and never get dragged back. The only way to tell if things are (aren’t) working right is to chat, cast a spell etc… something that uses the server. Generally you only notice a problem when a spell effect continues for too long, or your chat message dont show up or combat is messed up. The best way for a player to gauge the extent of the lag is to send a chat message and see how long it takes to come back.

#10

if thats an important feature in your game design, why not have a real ping instead?

At TEN we had something we called “Mr. bandwidth” that monitored your connectio nwith periodic pings and graohed your performacne for you. Frankly, all you need to do is time stamp each message and you have a built-in ping test thats a lot more accurate then bouncing chat.

This WOW business sounds like players hackign their way around a mis-design to me.

#11

Regarding WOW yeah, I guess it is.
There is a ping bar graphic in WOW but it averages so much (I think) that it rarely changes even when there is noticable lag in chat.
I suppose its just something I got accustomed to since the graph didnt work.

Its also very immediate. You really notice the problem when your message doesnt come back.
If you send it out, with a local echo and dont get an answer, your first expectation is that the problem is the person you are talking to isnt responding, not that there is a server problem.

Asherons Call had a much more accurate ping and actually gave the number, very helpful. Although some touchy feely designer types might not like it.

Not advocating one way or the other, just trying to make it clear why some people like it.

#12

[quote=“Tzan,post:11,topic:26805”]
“ping” means different things to different people. To some people, it’s the time it takes an IP ICMP datagram to travel through the network to the other host, and be echoed back to you using interrupt-driven host primitives. This does not include host load at all, in most cases. This is a network-layer ping.

For other people (this is especially common for FPS players), “ping” seems to mean the time it takes to send a packet, get that packet processed by the server, and receive the next update based on the results of that packet. Thus, if the server is chugging, “ping times” would go up, even though the intervening network condition hasn’t changed at all. This is an application-layer ping.

If chat has problems in WOW, but “ping” doesn’t change, then it’s not unlikely that there’s a problem with the chat distribution subsystem, but the network transport is just fine, and the WOW ping meter just displays the network conditions.

Now, if you think the overloading of the word “ping” is bad, try getting players and engineers to agree on what “lag” is … :wink:

#13

Actually thats easy.

Lag is not a phenomenon, its an experience.

Anything that causes a delay between the users’ actions and their pereception of response, is lag.

#14

I think as a player I would want application ping since it includes everything and can indicate a general problem.

#15

Application ping tells you that you have a problem, that’s true. But you’d probably notice anyway :slight_smile:

Network ping is more useful, in that it may help you figure out whether your problem is because of the network, or because of the application. If you’re having problems, but network ping is stable, then it’s likely the application.

#16

Or packet-loss… I often saw multiplayer FPS sessions where all pings of the player were below 100, yet it was lagging like there was no tomorrow. (?)

#17

Just to bring in more terminology - From a gamers perspective I associate ‘warping’ with packet-loss, not lag ;D

Though I suppose its down to the application as to how it resolves packet-loss, though most FPS’s i’ve played don’t bother resending non-critical lost data.
(afterall, if they did why would they be bothering with udp in the first place!)