Skip to content
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

RANT #1 Network Layer #614

Open
schmunzel opened this issue Dec 4, 2013 · 3 comments
Open

RANT #1 Network Layer #614

schmunzel opened this issue Dec 4, 2013 · 3 comments
Assignees

Comments

@schmunzel
Copy link
Member

I might simply be blind but while walking the code I found two things that really really bother me in the Network layer

  1. how are resends handled? is there a timer that handles resends when there is no answer by the client and if yes where the hell is it??

  2. how and where and when are Sequence overruns (65535 .. 0) handled

  3. we cant spam the client with to many packets as its udp buffer is finite !!!

As there has as of yet no testing with actual QA Team members it might not have occurred to anybody that remote people on the internet cant connect in 9 out of 10 cases while I still am not able to connect locally (!!!) in 1 out of 20 cases (!!!!!!!!!!!!!)

On the other hand in the packet captures I had the impression that the server is resending rather hysterically

I have not yet done a proper sequencing to debug this but I think that a proper assessment of the netlayers function in regard to what it will encounter in the wild should be a top priority

@ghost
Copy link

ghost commented Dec 4, 2013

+1

@schmunzel
Copy link
Member Author

Rant #2 Auto Sequencing of deltas
While I agree that auto sending of deltas is nice I really have to call the execution sloppy.
every time the factory loads the object with every call to to the setter routine a delta is created that is send to the client as soon as the first regular delta is created. This will result in desynchronization of the client and we wont have updates affecting the client.
With the current async handling of delta serialization a serialization of a delta might create 2 updates in one packet (which is fine) that will leave the second async request without a delta to create. Instead of bailing out we will just send an empty delta which again will desynchronize the client.

That I have now to go through every setter routine and every sender for every element of every view to remedy this wont make the issue better

AAARRRGHH

@ghost
Copy link

ghost commented Dec 4, 2013

+1

@ghost ghost assigned schmunzel Dec 4, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant