3 ms·
The dual stack thing is fixed with getaddrinfo. You’re probably speaking a protocol, I personally like to use regular languages with a reset byte (or octet or w
by swiley 7y ago
The dual stack thing is fixed with getaddrinfo. You’re probably speaking a protocol, I personally like to use regular languages with a reset byte (or octet or whatever.) at the beginning of every message. Since the data just goes into a state machine you can feed it partial messages and it will reconstruct them. This takes very little code, very little thought (just use Kleene’s algorithm) is extremely portable (unlike this which is exclusively apple) and very easy to mock and test.
Yes that still doesn’t take care of SOCKS but that (IMO) is heading into the “give the user an option to connect using pipes and netcat” territory (and that’s probably the best way to fix it.)
- TheTon 7y agogetaddrinfo isn’t a complete solution itself. This RFC describes what they’re doing: https://tools.ietf.org/rfc/rfc8305.txt https://tools.ietf.org/rfc/rfc8305.txt
- aseipp 7y agoIt's always hilarious to read the ever-puzzling reply that you see here, which is basically "Why don't you just manually re-build this design into every single application you've ever written, repeating yourself and scope for bugs 50x over, while I also ignore all other possible design constraints", and it never ceases to amaze me. The idea that a better abstraction for a component could exist or should be explored is strictly verboten.
- deleted 7y ago[deleted]
- swiley 7y agoAbstraction is great but this one locks your app into a single platform (and not only that, one that you often have to pay for the privilege of developing for.) Furthermore what I said really isn’t difficult, I recently wrote a protocol that way in two languages (C for an MCU and python for Windows) in a week, and as far as I can tell neither program has any serious bugs.