Archived
This forum has been archived. Please start a new discussion on GitHub.
Putting an adapter on hold, responding to ice_ping.
in Help Center
I have a client/server chatroom-like scenario where the server uses ice_ping() periodically to verify clients are still connected.
When a client joins it receives a bundle of information that can take the client a while to process. During this process time the client may malfunction if it receives updates from the server.
My first thought was to have the client put the adapter on hold after it gets the bundle, and then re-active it after it is ready to receive more updates.
It appears that the client does not respond to ice_pings from the server when the adapter is on hold. The server thinks the client has gone away when the client takes too long to process the first bundle.
I can come up with other ways to deal with this but I have a question about ice_ping and if this behavior is considered "correct." Is there a different way to postpone delivery of messages to servants that doesn't prevent the client from responding to pings?
Thanks.
When a client joins it receives a bundle of information that can take the client a while to process. During this process time the client may malfunction if it receives updates from the server.
My first thought was to have the client put the adapter on hold after it gets the bundle, and then re-active it after it is ready to receive more updates.
It appears that the client does not respond to ice_pings from the server when the adapter is on hold. The server thinks the client has gone away when the client takes too long to process the first bundle.
I can come up with other ways to deal with this but I have a question about ice_ping and if this behavior is considered "correct." Is there a different way to postpone delivery of messages to servants that doesn't prevent the client from responding to pings?
Thanks.
0