Slashdot Mirror
Unix Network Programming, Vol. 1
Those just starting in the field will eventually come across so many "Stevens book" references that it will eventually end up in their library. In a nutshell: Unix Network Programming is a must for anyone involved in writing network-enabled clients or server applications, requiring a variety of protocols.
The first edition of the book came out in 1990, and quickly became the college textbook and professional reference for anyone trying to get experience in the field. This is the third edition of first volume of Unix Network Programming, titled The Sockets Networking API. Volume 2 deals with Interprocess Communications and so far exists only in the 2nd edition. W. Richard Stevens didn't live to see the 3rd edition published, and the new book has Bill Fenner and Andrew M. Rudoff listed as co-authors.
The table of contents for Unix Network Programming provides a very good overview of what's packed into 31 chapters and 5 appendices that provide 950 pages of information on network programming (Addison Wesley states it's 1024 pages, but page 947 is the start of the bibliography, followed by an index which was designed by W. Richard Stevens himself for better usability). The book starts with the basics, with an introduction to network protocols and OSI model in chapters 1 and 2. The authors move on to socket programming (supporting TCP, UDP, and SCTP protocols), providing a working example of a TCP client-server application (Chapter 5) as well as SCTP client-server (Chapter 10). DNS service is covered in Chapter 10, with some additions dealing with IPv6 implementations.
The largest part of the book -- Advanced Sockets -- covers a wide range of technologies and generally it's not expected that you cover this part chapter by chapter. Chapter 12 would be of special use for anyone dealing with IPv4 and IPv6 implementations simultaneously. The authors provide an example of an IPv4 client working with an IPv6 server and vice versa. Then it proceeds to daemon processes, I/O operations on Unix, threads, raw sockets, advanced techniques for programming UDP and SCTP sockets, broadcasting and multicasting technologies, finishing off with the chapter on streams.
To avoid recapping the table of contents, it's worth mentioning that if you're an experienced network developer and have read previous editions of Stevens' book, you will find that that the book has been updated with IPv6 APIs and example code (including interoperation with IPv4 in aforementioned Chapter 12), information on the POSIX Single Unix Spec v3, a chapter on key management for IPsec (19), and three new chapters (9,10,23) on SCTP.
But wait a minute, what about the second edition, didn't it have 34 chapters, while this third one has only 31? Description of the XTI (X/Open Transport Interface) is gone, and that used to fill chapters 28,29,30,31 and 32 of the previous edition. The authors note that XTI API "has fallen out of common use and even the most recent POSIX specification does not bother to cover it." T/TCP (TCP for Transactions) is dropped as well, so if your applications still rely on either XTI or T/TCP, perhaps donating the 2nd edition to the local church library can wait.
The information above would be of interest to the professionals in the field, but what about the beginners? Can a reader expect to become proficient with developing network applications by absorbing Stevens' book? Unix Network Programming indeed makes a very good effort to be as inviting and simple as possible to the first-time reader, even while it is trying to be informative for those who've read the chapters several times. The authors generally start with the description of the solved problem, then specify the ways to solve the problem in English -- only after that do they introduce an example solution in C. The code is quite clean and universal to be re-used on Unix boxes with C++, Perl, etc. Where a proper OS function call is necessary, it's used with an explanation of what it does, and where the functionality asks for a new function, the authors introduce their own.
Don't let the word Unix in the title fool you into thinking that you will need a separate book for Win32 platform (or Linux, for that matter). Apparently, there are differences in OS-specific function calls, but as far as protocols and implementation of specific functionality, the book would provide useful examples for Microsoft developers as well. What about Apple Mac OS X? On page xxi the authors claim the code has been tested on Mac OS X on PowerPC, HP-UX 11i on PA-RISC, AIX 5.1 on PowerPC, FreeBSD 4.8 on x86, Linux 2.4.7 on x86, FreeBSD 5.1 on SPARC and Solaris 9 on SPARC.
If you're reading the book for the first time, but have been through a network class before, you might skip Chapters 1 and 2, where the basics of network interaction (port numbers, OSI model, Internet protocol suite, netstat command, TCP connections, etc.) are covered. It makes sense to peruse the starting chapters if you are not familiar with SCTP.
Since many colleges in the United States and around the world use this title for their network programming classes, a handful of exercises follows each chapter. The questions are not programming projects, just quick self-test opportunities, e.g. Chapter 18 (Routing Sockets) is followed by the question: "What would you expect the sdl_len field of a datalink socket address structure to contain for a device named eth10 whose link-layer address is a 64-bit IEEE EUI-64 address?"
Some of the things from Stevens' book (like the desire to write a wrapper function for everything) might drive you crazy, although if you accept the author's style and follow the textbook by typing up and trying the source code, you will end up with a rather nice API library for all occasions by the time you get through the first two parts. It would also certainly be nice if the book, despite the title, included at least an appendix on Windows-specific implementations for those developing clients for the Microsoft platform.
Unix Network Programming is indispensable if any part of your professional or academic career involves writing client-server applications or programs requiring network communications. A good knowledge of C and familiarity with Unix internals is required, while the book is gentle enough to provide good guidance for the beginner in the network programming field. As W. Richard Stevens' mentioned in one of the interviews, "When I hit something that I don't understand, I take a detour and learn something new. This often makes my books late by a few months, but I think accuracy and completeness are essential."
You can purchase Unix Network Programming, Vol. 1: The Sockets Networking API, Third Edition from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.
almost make me miss fp!!!!
-tirel of GNAA
I just installed gentoo and now I can't think of anything to do with it. What is gentoo good for?
[ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]
When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.
Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.
FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.
It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.
So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.
Discussion
I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.
From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.
There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.
Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.
Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?
Shouts
To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.
To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. I
is really great for network programming, it has one of the cleanest APIs and fastest TCP/IP stacks ever make. I swear if my boss makes me move to linux I will quit the job, it's that good!
I agree. I just installed Gentoo. "The greatest distro evar" they say. It took me 4 days of work to get from downloading the CD to my mouse scroll wheel working in Mozilla. Linux is truly not ready for prime time.
Bukkake!
ke ke ke
Try PyQT and Kugar.
It's powerful, and once you get past the whole OOP thing, it's brain-dead to use.
I'm still waiting for Crystal Reports on Unix tho... It's a better program.
Ok, I don't mean this to be offensive in any way, but how in the hell did stevens die? None of the obituaries say, and I'm a bit curious. How do we know that he didn't disappear into the bowels of the CIA or something? -puts on tinfoil hat-
"Quoting famous computer scientists out of context is the root of all evil (or at least most of it) in programming." - K
You comapre that to the millions and millions of driver problems that happen every day to win32 users? You sir, are an idiot. Sure, gentoo has problems, but then carrying that over to say that "every single lunix distribution is a piece of shit" is unintelligent, ignorant, and makes you a mindless automiton for the corporate FUD controllers to manipuate easily. An A/C is just that, A COWARD.
litigious bastards
suck it sco!
You, sir, have been trolled.
My university emphasized The Chicago Manual of Style over Elements of Style.
Go figure.
instead of reviewing boring books, maybe slashdot could be a forum for people to post sex stories involving Kathleen Fent?
Eh, fanboy?
I have, however, had to recompile the kernel from a red hat distro in order to get my logitech mouseman to work.
Yeah, I know.
Reviewing this book is like reviewing internet porn for slashdot readers!
Whackin',
Beyonce
how many Christians don't read the New Testament (or Old, for that matter).
Of Fent.
I hate to use Corba/RPC for IPC if applications are running on the same hardware , albeit diff. VMs.
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
Perhaps you should upgrade from Red Hat 6.0. Mice with wheels (USB and PS/2) have been recognized out-of-the-box for years with no configuring required.
Poor Hitlary. It seems that she found a bit of trouble locating troops that wanted to dine with her during her Thanksgiving trip to Iraq. At least our troops have the good sense to know when someone detests everything they fight for.
By Brian Briggs
Salt Lake City, UT - Supreme Court Judge Isaiah Moore ruled that SCO must show proof of Santa Claus in the next 30 days, or he will dismiss their lawsuit against all Christians and companies profiting from the Christmas holiday.
SCO, formerly known as Santa Cruz Operations, recently changed their name to Santa Claus Operations. This change was widely regarded as a move to improve their image after their controversial claims about Linux. Critics of the name change say it's just another fantasy created by SCO CEO Kris Kringle, formerly known as Darl McBride, to profit through litigation.
In a recent press release SCO said it would begin sending out invoices to anyone who celebrates or profits from Christmas in the next couple of weeks including corporations and individuals. A price list for SCO Christmas licenses which companies and individuals need to celebrate the holiday without violating SCO's intellectual property rights were released as well.
"Children can avoid penalties by sending 10% of their Christmas gifts to SCO," said Kringle.
Followers of the case consider the judge's decision a defeat for SCO, because they feel the company cannot prove the existence of Santa Claus.
Kringle was confident that SCO would prevail in the lawsuit. He said, "We have hundreds of e-mails addressed to Kris_Kringle@sco.com. Under Federal law it is illegal to route e-mail to the wrong location intentionally. This proves without a doubt that Santa Claus exists and he works at SCO."
Chief Counsel for the company Fred Gailey said he planned to print out these e-mails and place them in giant mailbags to dump on the judge's desk. "When the judge sees the number of e-mails we've received he will have to rule in our favor, or face breaking the hearts of his grandchildren."
"Christmas existed long before the existence of SCO," said VP of marketing for Giantco, Clayton Moneybags. "In fact I heard that at one point it was about celebrating the birth of Jesus."
SCO Vice president, Jesus Christ countered, "Don't you think we thought of that one too?"