3 ms·

The byproducts of reading OpenBSD netcat code

68 points by nanxiao 8y ago

lixtra 8y ago
TLDR: > reading classical source code is a rewarding process, and you can consider to try it yourself.
linkmotif 8y ago
Always refreshing to read and learn things things from enthusiastic lovers of learning.
derefr 8y ago
Is there any language that does something really different with its network abstractions, compared to just directly exposing the BSD socket API? I know that in Erlang for example, sockets are a type of actor, “owned” by the actor who spawns it, where the socket-actor will send its owner regular Erlang messages whenever it receives data; and where any actor can transmit data on the socket by sending an Erlang message to the socket’s actor. I’m curious what, say, socket interaction in a dataflow programming language looks like.
- CamTin 8y ago
  I've been doing some coding against the "distributed places" API in Racket, and it's been really nice to work with: https://docs.racket-lang.org/distributed-places/index.html https://docs.racket-lang.org/distributed-places/index.html
- Matthias247 8y ago
  The approach with Akka actors is similar - bytes are sent to and received from some kind of socket actor. I think Pony might do similar. Other than that: Go gets rid of exposing select() and co from the user and just offers blocking IO. Which is ok, since spawning goroutines is cheap and makes things more consistent than somewhere trying to do event-driven things. Other languages like C# also get rid of select, but offer asynchronous send/receive methods according to various conventions to the user. Still, that's also nothing fundamentally different. node.js might be a bit more different in the sense that the stack pushes received fragments towards the user inside a callback - there is no way to specify the target buffer into which the kernel will copy data on reception. And also in C, but still quite different from posix sockets: WinAPI in IO completion or registered IO mode. Calls to sockets no longer perform work synchronously, they just enqueue the work for the kernel, and results are obtained via an IO completion queue.
- exikyut 8y ago
  From https://news.ycombinator.com/item?id=7878679#7880362 https://news.ycombinator.com/item?id=7878679#7880362: > Genera on the Lisp Machine runs on the metal. [...] the network packets are Lisp arrays, ... Not a perfect system, but an interesting one.
- twic 8y ago
  Some languages have tuple spaces, or remote procedure calls. But those are usually implemented on top of a more raw socket API.
ninjin 8y ago
The code in question: https://cvsweb.openbsd.org/src/usr.bin/nc/ https://cvsweb.openbsd.org/src/usr.bin/nc/ Unless I am mistaken, it was not linked in the article.
- jwilk 8y ago
  GitHub mirror: https://github.com/openbsd/src/tree/master/usr.bin/nc https://github.com/openbsd/src/tree/master/usr.bin/nc
adtac 8y ago
For some reason, whenever I read any OpenBSD code, it looks just like code I would probably write. Maybe it's because they've kept it extremely plain and simple enough for someone who hasn't seen the code before to understand it in one sight. No crazy abstractions, quirks, new terminology. It's so refreshing.
aportnoy 8y ago
To summarize, the author started with brushing up on network programming and ended with submitting patches to OpenBSD. Cool.

68 points by nanxiao 8y ago

lixtra 8y ago

TLDR: > reading classical source code is a rewarding process, and you can consider to try it yourself.

linkmotif 8y ago

Always refreshing to read and learn things things from enthusiastic lovers of learning.

derefr 8y ago

Is there any language that does something really different with its network abstractions, compared to just directly exposing the BSD socket API? I know that in Erlang for example, sockets are a type of actor, “owned” by the actor who spawns it, where the socket-actor will send its owner regular Erlang messages whenever it receives data; and where any actor can transmit data on the socket by sending an Erlang message to the socket’s actor. I’m curious what, say, socket interaction in a dataflow programming language looks like.

CamTin 8y ago
I've been doing some coding against the "distributed places" API in Racket, and it's been really nice to work with: https://docs.racket-lang.org/distributed-places/index.html https://docs.racket-lang.org/distributed-places/index.html
Matthias247 8y ago
The approach with Akka actors is similar - bytes are sent to and received from some kind of socket actor. I think Pony might do similar. Other than that: Go gets rid of exposing select() and co from the user and just offers blocking IO. Which is ok, since spawning goroutines is cheap and makes things more consistent than somewhere trying to do event-driven things. Other languages like C# also get rid of select, but offer asynchronous send/receive methods according to various conventions to the user. Still, that's also nothing fundamentally different. node.js might be a bit more different in the sense that the stack pushes received fragments towards the user inside a callback - there is no way to specify the target buffer into which the kernel will copy data on reception. And also in C, but still quite different from posix sockets: WinAPI in IO completion or registered IO mode. Calls to sockets no longer perform work synchronously, they just enqueue the work for the kernel, and results are obtained via an IO completion queue.
exikyut 8y ago
From https://news.ycombinator.com/item?id=7878679#7880362 https://news.ycombinator.com/item?id=7878679#7880362: > Genera on the Lisp Machine runs on the metal. [...] the network packets are Lisp arrays, ... Not a perfect system, but an interesting one.
twic 8y ago
Some languages have tuple spaces, or remote procedure calls. But those are usually implemented on top of a more raw socket API.

ninjin 8y ago

The code in question: https://cvsweb.openbsd.org/src/usr.bin/nc/ https://cvsweb.openbsd.org/src/usr.bin/nc/ Unless I am mistaken, it was not linked in the article.

jwilk 8y ago
GitHub mirror: https://github.com/openbsd/src/tree/master/usr.bin/nc https://github.com/openbsd/src/tree/master/usr.bin/nc

adtac 8y ago

For some reason, whenever I read any OpenBSD code, it looks just like code I would probably write. Maybe it's because they've kept it extremely plain and simple enough for someone who hasn't seen the code before to understand it in one sight. No crazy abstractions, quirks, new terminology. It's so refreshing.

aportnoy 8y ago

To summarize, the author started with brushing up on network programming and ended with submitting patches to OpenBSD. Cool.