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

Do we really need the single connection iOS design? #751

Closed
yaronyg opened this issue Jul 11, 2016 · 1 comment
Closed

Do we really need the single connection iOS design? #751

yaronyg opened this issue Jul 11, 2016 · 1 comment
Milestone

Comments

@yaronyg
Copy link
Member

@yaronyg yaronyg commented Jul 11, 2016

Right now our iOS code allows for exactly one stream to exist in each direction between two iOS devices. The reason for this restriction is that we ran into issues when we let there be two streams in each direction. To be clear, the multi peer connectivity framework absolutely supports having multiple streams in the same direction. It does this by letting us give each stream a unique name. But in practice we had a lot of connection failures when we had two streams in the same direction.

So our fix was to only allow for a single stream in each direction and to then build a painfully complex mux layer at the Node.js layer of code to let us open TCP connections in both directions on that single underlying stream using our multiplex layer.

But we've always had the suspicion that the problems we ran into were the result of coding bugs on our part and not problems with the multi-peer connectivity framework. If that is true then we could get rid of the single stream restriction and radically reduce the complexity of our mux layer by creating a pair of streams in each direction for each device. This would let us treat each direction separately and have the identical behavior (and the identical Node.js code) for Android. It would also simplify the iOS native code.

@yaronyg yaronyg added this to the New Infra milestone Jul 11, 2016
@yaronyg yaronyg added 0 - Icebox and removed 0 - Icebox labels Jul 11, 2016
@yaronyg yaronyg closed this Aug 3, 2016
@yaronyg yaronyg added 4 - Done and removed 1 - Backlog labels Aug 3, 2016
@yaronyg
Copy link
Member Author

@yaronyg yaronyg commented Aug 3, 2016

No. We don't.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.