My current plan is to keep writing freely-available guides for as long as I can reach the keyboard. And maybe even longer with what will undoubtedly be awesome futuristic speech recognition--or mind-reading! That's not scary at all!
I'm leaning on bash/zsh scripting one I finish the utterly gigantic C guide I'm on now... hopefully later this year. But I'm always open to suggestion for topics... :)
This indirectly shaped my life in many ways. Thank you!
Let me give you a virtual elbow bump! You really made an impact in my academic and professional career!
OK, on 2003/07/06 15:11:16 the wayback machine captured Version 1.5.5 (13-Jan-1999). At the end it says:
Copyright © 1995, 1996
I'll read your future-brainwave-transmission tutorials, anytime, even if they run the risk of causing minor insanity!
I looked up the section on classful networking and CIDR and would like to make one addition that is often overlooked: in classful networking, not only are the network sizes fixed, but also where they reside in the IP address room.
E.g., class A networks used 0.0.0.0 – 127.255.255.255 whereas class C networks used 192.0.0.0 – 18.104.22.168.
With CIDR notation, not only can you have networks of different size, but they can start at arbitrary addresses.
If people talk about a class C network today, they often falsely relate to a network with 256 addresses - but which is located in the address room of original class A/B/D/E networks, for example.
Thank you so much for your time. I hope you realize how useful it's been.
And I'm also glad for the opportunity to directly thank you for the work you've put into this over the years :)
That would be amazing, I'd love to read a guide over scripting. The only request I would have is a section over sh as well if you do write such a guide.
Your book was what got me deeper into programming and networks in general back then, I have a full time job around this now. Thank you!
Such topics aren't dry and boring, they're fascinating and inspiring, and it's so valuable that you are able to present them that way.
(Would love to see your take on shell scripting!)
Keep up the great work.
P.S. Each time I do refer folks over or see a thread like this gives me fond memories of the O'Connell labs and the opportunities we had to enjoy networking in the early days.
The fun of the HP bug of the week and running a unix farm with shell accounts for all of us students.
Ended up working in infrastructure so eh, you kinda paved the way for me :)
You have made a huge positive impact.
Good to see that the guide is still being updated.
Is there any free or low-cost version?
My experience has been that there is rarely a backlog on technical materials like this.
: Example of for the LA public library of what I mean: https://lapl.overdrive.com/search?query=The+Linux+Programmin...
(In some ways, we benefit, since there is little pressure for the large publishers not to offer these kinds of things for free via the library system)
Ancedota (and unrelated to the topic of this thread, but interesting none the less I think):
In California, if you go to a state university (but if I recall correctly this doesn't apply to the University of California system, but the CSU system, if I got my facts straight) they must provide a minimum number of copies of each textbook / reading material required for a class be available via the campus library.
I hardly paid for books once I found this out. I just coordinated with others to make sure it was available when needed. Worked well for me.
I could be hazy on the regulation on this though, it might have just been dumb luck that the two places I went to school had this as a policy, but I remember it being explained as I did above.
I have fond memories of that guide and it's always a treat when it pops back up.
Well, some APIs are not meant to be used directly, but hidden behind a class or more application-specific functions.
I've made my own wrapper a few times but often don't get to use it for various reasons.
int tcp_connect(char* remote_host, short int port, options* options, static char** error_string);
int tcp_listen(short int port, options* options, static char** error_string);
int udp_listen(short int port, options* options, static char** error_string);
If you need something weird then you're back to the low level BSD socket stuff, but this covers about 95% of my use cases. While it's only saving a handful of system calls, it ends up being quite a bit of boilerplate and error handling. Especially if you specify a connect timeout, since that is kind of awkward to do with the BSD socket API.
2017 (a bit) https://news.ycombinator.com/item?id=13670971
2016 (a bit) https://news.ycombinator.com/item?id=12402313
2015 (a bit) https://news.ycombinator.com/item?id=9623813
2008 https://news.ycombinator.com/item?id=337371 ("Wow, I first read this when I was in high school. It's still being updated?")
It was wonderfully poetic to me that the same document that taught me how to make a wildly dangerous IRC bot in my teenage room for the lulz also re-taught me the stuff I needed to deliver a low-latency ML offloading demo at my serious(-ish) job 20 years later. Gave me a real warm fuzzy feeling :-)
HN disucssion anno 2015: https://news.ycombinator.com/item?id=9445692
Anno 2017: https://news.ycombinator.com/item?id=13983212
My experience with CTCP flooding large channels channels and causing netsplits in my youth provided a perfect base of understanding for when my production servers started flooding status updates to each other and couldn't stay connected.
PS sorry, undernet admins and users. Also, thanks to the admin on #quebec who asked me to flood his channel so he could tune his bot to block flooders.
I remember particularly enjoying the warm and jovial tone in his guide.
I first read through it some 20 years ago while being a student in an easter-european university, where the tone and style of professors was very "dictatorial", dry, and overly-technical.
Beej's style of exposure was a breath of fresh air, and brought a major realisation for the then young-me, that you can teach complex topics in a friendly manner.
I know it's just I typo, but now I have an image stuck in my head of a large rabbit, dressed up like Mussolini, lecturing about computer science.
Beej's guide was so amazingly helpful and welcoming when I found it over a decade ago.
Poorly written guides that try to be friendly or conversational are often worse than dry and terse guides of similar caliber, which really makes me appreciate the good and truly great ones.
And Beej's Guide is a truly great one.
If you want a cross platform network programming guide in C, Lewis Van Winkle has written an excellent reference book.
Aside from the book being really in-depth and understandable, Beej adds in quite a bit of humor and that is something I love in a good software book.
I also would mention Distributed systems for fun and profit
while being not exactly about network programming, it is likely a next step for anyone who's building apps that is scattered across several backends/services connected by the network
Brian Hall: thank you!
And here's some paywalled reporting from The Information with even more student complaints: "Lambda School's Growing Pains: Big Buzz, Student Complaints"
Please, tell me more about the view from the inside.
My first job out of university reqiured networking a small Linux device to an FPGA running a UDP stack, with nothing else. I'd never done anything with networking in C before, and this guide just made everything click
What does this suggest to you?
That we need a lot more addresses. That we need not just twice as many addresses,
not a billion times as many, not a thousand trillion times as many, but 79 MILLION
BILLION TRILLION times as many possible addresses! That’ll show ’em!
You’re saying, “Beej, is that true? I have every reason to disbelieve large numbers.”
Well, the difference between 32 bits and 128 bits might not sound like a lot; it’s
only 96 more bits, right? But remember, we’re talking powers here: 32 bits represents
some 4 billion numbers (232), while 128 bits represents about 340 trillion trillion
trillion numbers (for real, 2128). That’s like a million IPv4 Internets for every
single star in the Universe.
edit: it was the 90s
He's just joking of course. At first glance this seems like a great read. And he's funny too! :)
I do wonder how much of this is applicable to Rust though.
https://www.drdobbs.com/open-source/io-multiplexing-scalable... (Also covers select and /dev/poll but lacks epoll,kqueue)
I remember chatting in the fringes when nodeJS was doing their proper win32 porting and they did have some issues getting things stable due to lack of documentation but iirc got some help from MS so the libuv code should be usable as a reference for behaviours (As well as being fairly battle tested by now).
the latest variant is highly digestible. the struct walkthrus seem more accessible
It felt incredible that _I_ could do that as someone who had just started programming.
Thank you Beej.
I think it's now time to read this and find out all the stuff I got wrong and cement the stuff I got right.
I’ve been working on developing myself a custom ISDN stack recently. So far it’s just been me trying to design it at a high level without falling to feature creep.
PS Hello fellow toast
I'll definitely finish mine one day then. I was more interested in the IP layer when I did mine and learning about routing. TCP seemed a bit too complicated and not that interesting, but it would be cool to have at least once gone from a raw socket to HTTP.
I know exactly what you mean as well. When using technology there is a comfort in knowing that you could conceivably implement it yourself if you absolutely had to.
Cannot wait to see what you publish next, so glad you’ve decided to publish even more!
Can I use those low level API's or do you know some server/client libraries which simplify this for UDP and TCP channels?
There are also thousands of higher-level libraries that would let you avoid having to deal with these lower-level APIs directly.
As it stands, I don't think anyone can answer except it a completely generic way:
Almost every system has libraries to help, but it depends on what you're running on, what you're running over, and what you're trying to do.
If you're sending arbitrary chunks of data (like for a game), use a socket library. I've used WebSockets in the past, which handles the low-level stuff under the hood. There are libraries that implement it for Java, Go, C++, JS, etc. Check it out at https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...
It's not totally headache-free though - some issues I ran into were:
- running locally vs over the internet
- data formatting
- recovering from timeouts/dropped connections
> Your search - site:beej.us sctp - did not match any documents.
> About 9 results (0.25 seconds)
So I'd guess that the guide doesn't cover sctp.
(and more ...)
Just use they, it reads better and includes everyone instead of people with binary genders
But that's a problem for the future, right now “they” is usually the best inclusive pronoun available.
Moot point if it doesn't solve the issue of it still being binary, I guess.
I've been retraining myself to default to singular they. https://en.wikipedia.org/wiki/Singular_they
Old dog, new tricks. But I'm slowly adapting.