5 ms·

I disagree that TCP are an evolution of pipes. Pipes are unidirectional and have 2 file descriptors, which is way less confusing than TCPs behaviour with respe

by nly 4y ago

I disagree that TCP are an evolution of pipes. Pipes are unidirectional and have 2 file descriptors, which is way less confusing than TCPs behaviour with respect to EOF, shutdown and write()/read() error behaviour. A socket API that gave you two unidirectional fd's for a TCP socket would have been a massive improvement.

WJW 4y ago
TCP connections also have 2 file descriptors, they are just on different computers. It seems quite natural to me to think of a socket as two pipes joined together. As with so many things in computing the abstraction leaks a bit when you get deeper into it but as a first intuition for beginners I think you could do way worse than "a socket is a bidirectional pipe to another computer". I'm intrigued by your idea of making 2 file descriptors for each socket btw. Why would it be such an improvement in your opinion?
bigDinosaur 4y ago
You'll have a quibble with the name of a particular TCP/socket error then: EPIPE (seen as 'broken pipe').
wruza 4y ago
In two-fds tcp, FIN/ACK, RST, timeouts and desire to stay as non-blocking as possible would still be a thing, so we’d have all the same functions and behaviors, only SHUT_RD|WR parameters would go away. Pipes guarantee delivery if both sides agree, tcp doesn’t (but it tries hard asynchronously), that’s where the difference starts.
remram 4y ago
Some language APIs already have that capability, for example Rust (TcpStream::split() https://docs.rs/tokio/latest/tokio/net/struct.TcpStream.html#method.split https://docs.rs/tokio/latest/tokio/net/struct.TcpStream.html...) With the POSIX API, you can duplicate the socket file descriptor, but calling shutdown() to close one direction of a file descriptor will actually close that direction on all file descriptors... unfortunate.
dragontamer 4y ago
> I disagree that TCP are an evolution of pipes. Pipes are unidirectional and have 2 file descriptors, which is way less confusing than TCPs behaviour with respect to EOF, shutdown and write()/read() error behaviour. TCP is complicated. But "stream based sockets" aren't "just" TCP (ex: Unix domain sockets fixes all of the "glitches" of TCP). The important bit of "sockets", in general, is the concept of: 1. "Accepting" file descriptor (creates new file descriptors whenever someone is "connecting" to you). 2. Multiplexing and "juggling" those descriptors. TCP fits this model, though with some low level quirks. Unix Domain Sockets are arguably the place to start, but most beginner programmers wouldn't find that useful (they really want internet connections). ------------- Its difficult to make a "server" off of one pipe. Maybe two pipes (first pipe accepts requests and divvys out new pipes to work off of). But no matter how you do it, its wonky. A proper server needs that "accept" abstraction, which is completely missing from pipes.
- nly 4y ago
  > A proper server needs that "accept" abstraction, which is completely missing from pipes. You can receive file descriptors over a UNIX socket, but yeah. That said I don't see why a file descriptor is a good abstraction for a listening socket in the first place when you don't read() or write() to it.

by nly 4y ago

WJW 4y ago

TCP connections also have 2 file descriptors, they are just on different computers. It seems quite natural to me to think of a socket as two pipes joined together. As with so many things in computing the abstraction leaks a bit when you get deeper into it but as a first intuition for beginners I think you could do way worse than "a socket is a bidirectional pipe to another computer". I'm intrigued by your idea of making 2 file descriptors for each socket btw. Why would it be such an improvement in your opinion?

bigDinosaur 4y ago

You'll have a quibble with the name of a particular TCP/socket error then: EPIPE (seen as 'broken pipe').

wruza 4y ago

In two-fds tcp, FIN/ACK, RST, timeouts and desire to stay as non-blocking as possible would still be a thing, so we’d have all the same functions and behaviors, only SHUT_RD|WR parameters would go away. Pipes guarantee delivery if both sides agree, tcp doesn’t (but it tries hard asynchronously), that’s where the difference starts.

remram 4y ago

Some language APIs already have that capability, for example Rust (TcpStream::split() https://docs.rs/tokio/latest/tokio/net/struct.TcpStream.html#method.split https://docs.rs/tokio/latest/tokio/net/struct.TcpStream.html...) With the POSIX API, you can duplicate the socket file descriptor, but calling shutdown() to close one direction of a file descriptor will actually close that direction on all file descriptors... unfortunate.

dragontamer 4y ago

> I disagree that TCP are an evolution of pipes. Pipes are unidirectional and have 2 file descriptors, which is way less confusing than TCPs behaviour with respect to EOF, shutdown and write()/read() error behaviour. TCP is complicated. But "stream based sockets" aren't "just" TCP (ex: Unix domain sockets fixes all of the "glitches" of TCP). The important bit of "sockets", in general, is the concept of: 1. "Accepting" file descriptor (creates new file descriptors whenever someone is "connecting" to you). 2. Multiplexing and "juggling" those descriptors. TCP fits this model, though with some low level quirks. Unix Domain Sockets are arguably the place to start, but most beginner programmers wouldn't find that useful (they really want internet connections). ------------- Its difficult to make a "server" off of one pipe. Maybe two pipes (first pipe accepts requests and divvys out new pipes to work off of). But no matter how you do it, its wonky. A proper server needs that "accept" abstraction, which is completely missing from pipes.

nly 4y ago
> A proper server needs that "accept" abstraction, which is completely missing from pipes. You can receive file descriptors over a UNIX socket, but yeah. That said I don't see why a file descriptor is a good abstraction for a listening socket in the first place when you don't read() or write() to it.