I'm adding support to the Primus-Objc library to allow a client to stay connected while the application is in background mode. This is an incredibly useful feature for VOIP applications, for example.
I will be implementing this by asking the OS to wake my application and execute a handler every 10 minutes (10 minutes is the minimum amount).
Currently this is impossible due to the zombie timeout feature on server-side primus, which defaults to 35 seconds. I know this feature can be disabled (or increased to 10+ minutes) on the server-side, but it is actually a very useful feature that has killed many stuck connections for us.
I'd like to suggest adding a special parameter to the ping heartbeat to overwrite the zombie timeout only for that client (since we still want Web browsers to use the default timeout).
For example, the client could send the message: primus::ping::<timestamp>::600000 to indicate that the next ping will only be sent after 600 seconds (10 minutes).
What do you guys think?
This seems a useful feature for particular use cases like the one you are describing.
I'm ok with this.
Sounds good to me as well but can't this be leveraged as way to attack servers? Create a zombi connection, send a primus::ping::<timestamp>::<1 day> to the server and kill the connection so it will not be cleaned up on the server, and repeat with 1000's of connections, it would eventually explode the server out of memory.
true, i didn't think about that.
This problem already exists today since the default value is 35 seconds and within that interval it is still possible to exhaust the server's memory capabilities. Considering this, we could optionally offer the client a maximum timeout value defined on the server. It doesn't fix the issue, but at least it wouldn't allow clients to set a very large timeout like a full day.
Another option would be hiding this information from the client and pass a client option/type instead when connecting. We could then tune certain server properties according to the client type (e.g. "mobile"). This would make it quite practical to define settings like message buffer size and connection timeouts.
@ruimarinho That is true that it's already possible today, but it would be substantially harder to completely kill a server within 35 seconds compared to setting the timeout to a day AND the server has the control over the value, not the client. So if you are victim of an attack you could lower the timeout to get things under control again.
I do like the idea of allowing different settings per connection type this makes a lot of sense and would still give the control with the server and developer instead of an attacker.
Good idea @ruimarinho 👍
I was going to suggest a max timeout on the server as well, but I like the multiple-settings approach better.
I'll try to come up with a PR during the next week.
Nice call @ruimarinho.
@nunofgs sounds good, i'll keep an eye out for that pull request ;-)