some clients not recieveing extension responses?

[foxter888]

well i know some people might think that i'm not doing the responses right by asking here on this forum, anyhow the problem i see it's more different.
all the extension responses work fine for example if my player dies in my fps game setup and then he respawn, he sends a extension request for respawning then the other clients recieves it and spawn the remote.

now the weird issue is that every once in a while there is a client that didn't recieve the server event.

every one got the event normally except for one randomly. is there something else behind this making shure that is being fired off or not?

[Lapo]

I am sorry to say that generic questions like there will unlikely receive any help.
If you want us to help you should provide the details of the issue and possibly a way for reproducing it.
Please read here:
viewtopic.php?t=3307

[foxter888]

so i'm guessing the correct way to say it is that i have regular messages that are not udp being dropped, making the clients to fall out of sync, thus creating a pitfall on the game.

[foxter888]

is there a way to make it so certain packets can't drop such as them having priority?
what i'm experiencing is that the other client it's slow and after a while he drops one packet which happens to be tcp in this case is a respawning message
so then it breaks the game, i am using udp and i understand that they can be dropped which is fine.

[Lapo]

The reasons for dropped messages have been discussed so many times in this forum. Essentially it boils down to three possible causes (or a mix of them:

1- too high message rate from client to server
2- lack of server bandwidth
3- client sloppy connection


In addition to this, the server will tell you the percentage of dropped messages, a value <=10% is to be considered normal especially if it's an action game. It is just common that some users have bad or slow connection and are not able to keep up.

[foxter888]

i do get the three points that you are mentioning, but what seems a bit exagerating is the fact that tcp messages are supposed to be reliable, so far i have done just like the manuals says and even the tutorials you all have been showing, same way as the fps demo and so on and even lowering the rate of messages more to the point where the game moves very unreal and skippy because of not recieving positions on a good rate and so on and still the other messages get drops every once in a while.

it seems very unstable to me on this perspective, are you guys trying to work on a fix for it or so? like if i compare it to other network solutions like in so many several games i have seen games with super had connection lag still running normal and able to correctly run it's mechanich.

and yes i canunderstand that udp messages which are normally used for movement in which i do will be dropped since they are unreliable but TCP?

[Lapo]

Yes, TCP guarantees delivery but the Server doesn't under some very specific circumstances.
When a client is too slow the server has to slow down too even if there are already new messages to send. So the server keeps all these new messages that cannot be delivered in a queue and waits for the client to be ready to receive more data.
This client queue is not infinite, it has a top boundary (by default 120 msg). When that limit is reached each subsequent message is dropped.

If there was no boundary the server would eventually eat up all memory and crash, which is not nice You can fine tune the limit and the Server already drops certain unimportant messages when the queue is reaching the limit. My suggestion is that if you see a lot of dropped data something is not right and you should investigate the three most common culprits.

If you already have taken care of the message rate then it's time to look into the bandwidth problems. Final thought: you said you didn't use UDP because it's unreliable but the that is something we all must live with. Actually UDP gives you a higher message rate and smoother action when the connection is good and the prediction algorithm allow you to fill-in-the-blanks when data is having a hiccup.
If you're working on an real-time project I'd recommend to use UDP together with the techniques explained in the FPS whitepaper.

[foxter888]

i do use udp for the movements, and yes i can understand them dropping due to their nature, i do apreciate the help you are giving me.
yes the other client connection seems to be somewhat slow and when looking at their pings i can see how is their connection.

so far it seems to make the project a bit more unrealistic not being able to account for it and that's why i asked if there was a way into making shure some messages have a priority of not droping which causes the game loop to break.

and yes i have been following the manuals and tutorials as it is, so far i'm getting pretty proficient with most of the aspects of smartfox except for some such as class serialization.

my connection is a 50mb connection so far so my bandwith it's actually pretty good and a very high responsive network for a development setup.
and yes i'm planning to later on go for eigther a dedicated server and or a cloud maybe?

there are still other network concepts i would like to learn like AI controlled by the server, Collisions on the server, i just don't have the good resources that are well explained. yes i can see some of it happening in the fps tutorial, still it's not sufficient enough for me.

what are your recomendations when dealing with a client that is very slow or what not? how to account for it? how can i make it so the message is sent correctly even do it can be dropped? is there a way to like make it so it would send the message and check is it was droppedor some way of controlling it? such as make it to keep sending it until reached? should of i made it into a udp message even do it can be dropped to? so far with udp all i know is that i should mainly use it for things like positions besides having the interpolation algorithm.

should of i used something else instead of the extension request? like maybe the other features such as user variables?or object messages? does this mean that even chat messages can be dropped to such as the public and private messages?

[Lapo]

Code: Select all

what are your recomendations when dealing with a client that is very slow or what not?

If clients are too slow for the game there's nothing they can do about, If you ever played Unreal, Quake Arena etc... online. When you have slow connection everyone is stuttering, they fire at you but you can't see them, it's just unplayable. The best thing you can do is offer a visual representation of the ping time to the client via a colored bar or gauge that shows how their connection is performing.
With a lag < 100ms they should get a green color (good), between 100 and 200ms a yellow (could be better), > 200ms bad. This way the user has a visual feedback of his connection. And if the game is stuttering he'll know why.

how can i make it so the message is sent correctly even do it can be dropped?

A message is not dropped until the queue is full, once it is full there's no priority that can help, the queue is full, end of story The idea is to fine tune the queue, but again pushing it over 120 messages is of no use in a realtime game. It could work in a chat or turn base application, probably.
If a player is 120 updates behind the other players he's already experiencing an horrible gameplay.

is there a way to like make it so it would send the message and check is it was droppedor some way of controlling it?

Again what's the point?
There are already 120 messages to be delivered before this one. Can this make any difference? The answer is no. If the queue could contain 10 messages I would agree.

should of i made it into a udp message even do it can be dropped to?

I don't think so. Move updates are "expendable" but other game messages should always be delivered.

Bottom Line:
At the end of the day what counts is the percentage of dropped message, as I mentioned in the first reply. Any number <= 10% of dropped packets should be acceptable because this is the nature of the network and not all clients have fast and efficient connections.
When the amount of packets lost breaks that barrier you should start checking for other problems such as those I've mentioned earlier.

[foxter888]

yes i get most of what you are mentioning, so far seems to work fine with some players and some with bad connection not so much. it does feels bad to know that we can' always have a decent connection lol