
The byproducts of reading OpenBSD netcat code - nanxiao
https://nanxiao.me/en/the-byproducts-of-reading-openbsd-netcat-code/
======
derefr
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.

~~~
Matthias247
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.

------
ninjin
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
GitHub mirror:

[https://github.com/openbsd/src/tree/master/usr.bin/nc](https://github.com/openbsd/src/tree/master/usr.bin/nc)

------
adtac
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.

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

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

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

