3 ms·

Nope. It's a platform for delivering packaged and reusable distributed algorithms, such as request/reply or publish/subscribe. The algorithms handle the issues

by rumcajz 13y ago

Nope. It's a platform for delivering packaged and reusable distributed algorithms, such as request/reply or publish/subscribe. The algorithms handle the issues like message routing, scaling up, handling partial failure etc.

derefr 13y ago
Well, that's what I meant--technically, BSD sockets are themselves supposed to be "a platform for delivering packaged and reusable distributed algorithms". In a friendly, ideal environment (like the Internet of the 1980s), req/rep is "just" TCP/SCTP unicast, pub/sub is "just" UDP multicast, and so on. Issues like "message routing [and] scaling up" are supposed to be handled on the link layer (i.e. using ARP, BGP, etc.); issues like handling partial failure, on the transport layer (if IP stacks weren't stuck in the 70s, we'd have such a thing as multicast TCP, and "send TCP packet to host set, wait for ACK from all hosts, and retransmit to failed hosts" would simply be its obvious send() system-call semantic.) We've just screwed the "friendly, ideal environment' pooch by putting not-very-intelligent NATs and firewalls everywhere. So we have to, sadly, reimplement all these nice things on top of the few things we've kept working: TCP and UDP unicast from clients to "business-leased" IPs with open+addressable ports. The necessity of things like this, UPnP, and TURN/STUN/ICE sadden me sometimes, they really do; they're 100% examples of an inner-platform[1] created because software developers have gone on for so long only touching OSI layer 7, and thinking about the rest of the infrastructure as a black box, that now the application layer is the only place you can solve problems, because the infrastructure will no longer transport your packets if they do anything special below it. So I say, please, look past your abstractions, programmers, and learn what makes the Internet tick! It's worth it to understand what your packets are doing--you might want a property that you can already get by asking something different of a lower layer. Or, even if not, you might just become--as Bret Victor says--very unsatisfied with the state of things. :) Oh, and start here, if anywhere: http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html --- [1] http://en.wikipedia.org/wiki/Inner-platform_effect http://en.wikipedia.org/wiki/Inner-platform_effect
- rumcajz 13y ago
  You are oversimplifying it. REQ/REP is not the same as TCP, unlike TCP it works with multiple requesters and multiple repliers. Same with other patterns. The main distinction between L4 and scalability layer is that L4 works between 2 nodes, scalability between arbitrary number of nodes. There's the special case of UDP multicast, but the multicast itself feels more like a hack rather than a real L4 protocol.
- aidenn0 13y ago
  Can we stop using OSI layer numbers for TCP/IP? Why did that ever catch on?

by rumcajz 13y ago

derefr 13y ago

Well, that's what I meant--technically, BSD sockets are themselves supposed to be "a platform for delivering packaged and reusable distributed algorithms". In a friendly, ideal environment (like the Internet of the 1980s), req/rep is "just" TCP/SCTP unicast, pub/sub is "just" UDP multicast, and so on. Issues like "message routing [and] scaling up" are supposed to be handled on the link layer (i.e. using ARP, BGP, etc.); issues like handling partial failure, on the transport layer (if IP stacks weren't stuck in the 70s, we'd have such a thing as multicast TCP, and "send TCP packet to host set, wait for ACK from all hosts, and retransmit to failed hosts" would simply be its obvious send() system-call semantic.) We've just screwed the "friendly, ideal environment' pooch by putting not-very-intelligent NATs and firewalls everywhere. So we have to, sadly, reimplement all these nice things on top of the few things we've kept working: TCP and UDP unicast from clients to "business-leased" IPs with open+addressable ports. The necessity of things like this, UPnP, and TURN/STUN/ICE sadden me sometimes, they really do; they're 100% examples of an inner-platform[1] created because software developers have gone on for so long only touching OSI layer 7, and thinking about the rest of the infrastructure as a black box, that now the application layer is the only place you can solve problems, because the infrastructure will no longer transport your packets if they do anything special below it. So I say, please, look past your abstractions, programmers, and learn what makes the Internet tick! It's worth it to understand what your packets are doing--you might want a property that you can already get by asking something different of a lower layer. Or, even if not, you might just become--as Bret Victor says--very unsatisfied with the state of things. :) Oh, and start here, if anywhere: http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html --- [1] http://en.wikipedia.org/wiki/Inner-platform_effect http://en.wikipedia.org/wiki/Inner-platform_effect

rumcajz 13y ago
You are oversimplifying it. REQ/REP is not the same as TCP, unlike TCP it works with multiple requesters and multiple repliers. Same with other patterns. The main distinction between L4 and scalability layer is that L4 works between 2 nodes, scalability between arbitrary number of nodes. There's the special case of UDP multicast, but the multicast itself feels more like a hack rather than a real L4 protocol.
aidenn0 13y ago
Can we stop using OSI layer numbers for TCP/IP? Why did that ever catch on?