-
Notifications
You must be signed in to change notification settings - Fork 12
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
broadcast syncing for reduction in redundant traffic #35
Comments
+1 |
I originally planned to implement this with Multicast on ip6 enabled hosts. I'll have a look into how much work is involved in making this work. You guys will wind up with what amounts to your own |
We tried IPv6-over-AX.25 on Friday and Saturday nights - the kernel (v3.8.7 and v3.9.4) doesn't support it, just IPv4. |
you could also use udp/sctp + ipv4 |
Funny you should mention that- we were looking at sctp last night in the context of http/2 (which is a tempting candidate for a switch in the core driver). I'm going to focus on the sync algorithm first anyway, because it doesn't matter how good your transport is if you're sending megs of unnecessary data. Thanks for the links though, being able to bench a working implementation ftw. |
also sctp is available via the socket module though it isn't part of the variables made available in the python api. yeah, it should be close to a drop in replacement so no sense in jumping the gun just to fiddle with it. |
for layer 1's with a literal broadcast (adhoc wifi, amateur radio, etc), syncing with a broadcast reply to requests would let others in range receive data without needing to send a request. thus freeing up the collision domain for data to flow rather than sync requests and repeated retransmission of the same data.
The text was updated successfully, but these errors were encountered: