-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Client disconnection when part not found? #282
Comments
Most elegant solution I found to this is a mechanism to allow a manual flush of the queued multipart write streams. |
It would be nice if I read these more often, been very busy, anyway. The problem is that the network model is one of guarantees, and if the guarantee isn't met (that the packet reaches the tile on the client) anything could happen depending on the individual part implementation. Yes this is a disadvantage of sending deltas rather than complete states, but there's not much that can be done. Consider more critical packets like addition and removal of parts. I see the issue is that the frame sends its movement packet immediately, but the multipart waits till the end of the tick, so they get out of order. Seems to be a disadvantage to my design, but I'm not sure what can be done about it. |
I don't think anything would be incorrect with being able to manually send the data during the tick. For example, before the tile is actually moved, if the data was sent, followed by a packet that actually moves the tile client-side, it would be read before the move. |
Aah right I understand now. You want a way to flush the multipart packets early so you can interleave your own. I'll think about a solution for this |
Consider a scenario when a server multipart sends its stream over to the client. However, before it gets there, the multipart block is moved by a frame... Client is kicked by a 'client multipart not found' message. Perhaps something can be made to redirect packets?
The text was updated successfully, but these errors were encountered: