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.
SCO: The GNAA-Nigerian connection Dear Sir/Madam:
I am Mr. Darl McBride currently serving as the president and chief executive officer of the SCO Group, formerly known as Caldera Systems International, in Lindon, Utah, United States of America. I know this letter might surprise you because we have had no previous communications or business dealings before now.
My associates have recently made claim to computer softwares worth an estimated $1 billion U.S. dollars. I am writing to you in confidence because we urgently require your assistance to obtain these funds.
In the early 1970s the American Telephone and Telegraph corporation developed at great expense the computer operating system software known as UNIX. Unfortunately the laws of my country prohibited them from selling these softwares and so their valuable source codes remained privately held. Under a special arrangement some programmers from the California University of Berkeley did add more codes to this operating system, increasing its value, but not in any way to dilute or disparage our full and rightful ownership of these codes, despite any agreement between American Telephone and Telegraph and the California University of Berkeley, which agreement we deny and disavow.
In the year 1984 a change of regime in my country allowed the American Telephone and Telegraph corporation to make profits from these softwares. In the year 1990 ownership of these softwares was transferred to the corporation UNIX System Laboratories. In the year 1993 this corporation was sold to the corporation Novell. In the year 1994 some employees of Novell formed the corporation Caldera Systems International, which began to distribute an upstart operating system known as Linux. In the year 1995 Novell sold the UNIX software codes to SCO. In the year 2001 occurred a separation of SCO, and the SCO brand name and UNIX codes were acquired by the Caldera Systems International, and in the following year the Caldera Systems International was renamed SCO Group, of which i currently serve as chief executive officer.
My associates and I of the SCO Group are therefore the full and rightful owners of the operating system softwares known as UNIX. Our engineers have discovered that no fewer than seventy (70) lines of our valuable and proprietary source codes have appeared in the upstart operating system Linux. As you can plainly see, this gives us a claim on the millions of lines of valuable software codes which comprise this Linux and which has been sold at great profit to very many business enterprises. Our legal experts have advised us that our contribution to these codes is worth an estimated one (1) billion U.S. dollars.
Unfortunately we are having difficulty extracting our funds from these computer softwares. To this effect i have been given the mandate by my colleagues to contact you and ask for your assistance. We are prepared to sell you a share in this enterprise, which will soon be very profitable, that will grant you the rights to use these valuable softwares in your business enterprise. Unfortunately we are not able at this time to set a price on these rights. Therefore it is our respectful suggestion, that you may be immediately a party to this enterprise, before others accept these lucrative terms, that you send us the number of a banking account where we can withdraw funds of a suitable amount to guarantee your participation in this enterprise. As an alternative you may send us the number and expiration date of your major credit card, or you may send to us a signed check from your banking account payable to "SCO Group" and with the amount left blank for us to conveniently supply.
Kindly treat this request as very important and strictly confidential. I honestly assure you that this transaction is 100% legal and risk-free.
Signed, GNAA president
PS. If you have mod points and would like to support GNAA, please moderate this post up.
___________________________________________
Politicians are all the same, they promise to build a bridge even when there is no river.
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
Its way to complicated and its only free if your time is worth nothing.
Given a choice of Windows 95 and the latest and greatest GNU/LuniX distribution I would take Windows 95 anyday. Microsoft makes it much easier for the average user to configure the system as well as for the developer to make a high quality application.
Maybe GNU could learn something from VB.
according to:
p ru g/29-1.html
http://www.roguewave.com/support/docs/hppdocs/t
An excellent introduction and reference for the various Unix C IPC mechanisms. Also famous as the book that the girl of Garth's dreams is carrying at the end of Wayne's World II.
What there ought to be is some sort of environment where developers can use a simple markup language to describe a GUI and have some easy to use hooks back to a server machine which could run some code and generate reports to be delivered back to the GUI.
If there were only some software to fill that gap...
I have been pwned because my
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!
- TCP/IP Illustrated, Volume 1: The Protocols
- UNIX Network Programming
More information here - http://www.kohala.com/start/My mom never taught me to sign.
Bukkake!
ke ke ke
This is the best darn book on network programming bar none. I wore the covers off the 1990 edition I first owned and had to get it rebound.
Looking at the ToC on Amazon's page for this book, it says Stream Control Transmission Protocol, and is in the same chapter as TCP and UDP, implying it's a transport layer protocol. I've never heard of it. Anyone know of a decent tutorial page on it?
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
The next day if you go by there you see mounds of garbage, not the least of which are USED shit-laden disposable diapers left on the ground wherever the spicette happened to change her whelp. Wine bottles, beer cans, chip wrappers, every kind of garbage is just left there on the ground for the city to clean up.
Those people are sub-human animals with no regard for the environment, no regard for sanitation, and certainly no regard for the rule of law. They completely disgust me. One spic easily pollutes as much as ten humans.
Unix Network Programming is akin to reviewing the New Testament for a Christian audience, or The Elements of Style for English majors.
would it also be akin to reviewing Battlefield Earth for Scientologists?
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
I checked out the 2nd edition from my school's library (I'm surprised they have it). I currently don't have time to read it, so I'm aiming for racking up the most geeky and largest fine I can @ $0.10 per day, and there's a whole semester to go!
.. assuming this "Unix" thing ever takes off..
nasty links above!!
My university emphasized The Chicago Manual of Style over Elements of Style.
Go figure.
Personally, I'll just wait for TAOCP volumes 9 and 10 which will be the definitive guide on network programming for all operating systems.
Xemu will get you for that.
instead of reviewing boring books, maybe slashdot could be a forum for people to post sex stories involving Kathleen Fent?
...without the slashdot referral fee, from Amazon and B&N
Eh, fanboy?
I feel fortunate to have a signed first edition of the book. In 1993, while doing an internship at IBM and working on a sockets-related project, we brought Rich Stevens (how he signs his name) in to teach a two-day class. He had a knack for taking complicated subject matter and presenting it in an easy-to-understand, straightforward manner.
ref=sr_11_1/103-0663527-6482268
So, your referral fee is somehow better than Slashdots? For you maybe.
99.99999999% of the world responded, "I really don't care. And what the hell is a Unix?"
Sockets are overrated.
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 have both this book and Microsoft's take on network coding. The Stevens book has been much more useful, and not just because I've needed to write Windows clients and Linux servers that interoperate. There aren't many differences between Windows Sockets and the BSD socket interface:
If you keep this info in mind, you can apply most of what's in the Stevens book under Win32 nearly as easily as you can under Linux/*BSD/whatever. You'll also end up with network code that's reasonably easy to port elsewhere...more so than if you go for a larger percentage of Microsoft-specific socket calls (many BSD-style calls have WSA* near-equivalents that you can use).
20 January 2017: the End of an Error.
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?"
U R TEH FUNNIE!!!1~
how can the publishers get away with selling this book for 70$? the usual excuse for technical books being expensive is that they do not sell in large quantities, but that does not apply for this one. and it is the 3rd edition. and the last review consisted mainly in removing content...
Dev elpizw tipota, dev phoboumai tipota eimai lephteros http://euclidian.org
Shame nobody stopped to mention that Rich Stevens passed away in 1999.
-psy
This AC: fag 100%. No doubt about it. Trying to sneak in a quickie.
It has been years since I read this in college. I kept the book, and it is *somewhere*. Very useful. Very good for understanding how TCP/IP works because of the programming examples.
The most useless part? The portmapper and the r* commands. Why? Because, IMHO, the portmapper really is a stupid service in the modern world (aside from protocols which now depend on it). Almost nobody in their right mind makes those kind of services. But I suppose, for completeness sake, I'm glad it was in there.
Sounds exactly like a book I would like to buy.
/.
Good job on another quality book review
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
Dude, if you are writing high performance servers
P ostQueuedCompletionStatus(...)
:-)
in Win32 you are shit out of luck using the BSD
style calls. The only way to got on Win32 for
scalable performance is overlaped I/O on sockets.
The calls that should be of interest to you are things like:
AcceptEX(...)
GetQueuedCompletionStatus(...)
etc, etc. Totally non-portable but who cares
- Moomin
Slashdotter, please do not equate the rampart downmodding of the parent with falsely claimed merits of FreeBSD. FreeBSD is an excellent development and deployment environment to be used the fine networking book reviewed here.
It's just the cft is a troll, and a fucking fag.
From the review:
W. Richard Stevens didn't live to see the 3rd edition published
Undoubtedly one of the best technical books that has ever been written. From the review: perhaps donating the 2nd edition to the local church library can wait. Also, if you happen to have the first edition of the book (or if you happen to lay your hands on one) don't give it away either. (Note: UNIX Network Programming, first edition was only a single volume edition). The first edition had an entire chapter on printer spooler application, which was not included in the second edition. (Please correct me if I am wrong...the application was definitely not in Vol I of second ed, but might have been included in Vol II, although I remember having looked for it in the 2nd edition and not finding it...I had to dig out a copy of the first edition from a Motorola warehouse...)
for sure
When i first saw the article, I thought - finally, the third volume. There were some rummors that Gary Wright, that was co-author in TCP/IP Illustrated Vol.2, was going to finish UNP vol.3....
... :)
I'd love to get this third edition, though... I was used to read UNPv1 before going to bed
Or you could just use Twisted and make it relatively easy ...
I use the book at work. Its been very very helpful. However its not for those new to programming, as it not always the clearest book although the most comprehensive I've found.
I also don't like his examples, which tend to use his own libraries which makes them more confusing.
Note that Vol II is IPC and is similarly useful/ challenging.
People get this mixed up alot. The poorly named (in my opinion) Networking Programing Vol II covers IPC(message que/shared memory....) Network programming Vol I covers sockets (udp/tcp etc).
I still think it funny the book is in waynes world..
Or in ebook? I'd love to have it with me all the time sans lugging the big book around. I'd gladly pay for the ebook.
... if this book is a SCO-code-free product... you can never be sure!
This book was already reviewed on Slashdot.
Okay, okay, that was five years ago (to the day!), but how much can really have changed?
:wq
dot.com go boom; ask my bank account. I can no longer afford this book. :(
Shut up shut up shut up I can't believe you don't shut up!
:)
L. Ron will _get_ you for that...
In a nutshell: Unix Network Programming is a must for anyone involved in writing network-enabled clients or server applications
I thought the publisher was Addison-Whatever, not O'Reilly?
Yay me!
Heres an interesting article
about Stevens over at Salon.
I can tell you the meaning of life,
but you have to promise not to laugh.
I bought copies of Stevens "Unix Network Programming: Networking API's - Sockets and X11 Second Edition" and "Unix Network Programming: Interprocess Communications Second Edition". Information is very clearly presented. These are the books to read if you want to learn how TCP/IP works on Linux, Unix, MacOSX or even the lifted BSD code found in recent Microsoft systems (yep, they lifted the code from BSD when their own winsuck protocol was finally taken out and shot). Stevens work is more readable than RFC's but just as thorough. Too bad my university didn't use them.
it must take to think "why don't I write a review of one of Richard Stevens' programming books" is simply astounding.
Does just what you describe.
Sorry y'all, but Stevens goofed with this series. He goes over bunches of "upcoming" APIs that just never up and came. Named semaphores? Really? What implementation of UNIX do you know with named semaphores? Come on. The last Stevens book on UNIX IPC and Sockets programming that's pretty universal is APUE.
But even his collection of vaporware APIs is not my biggest problem with this series. It's too long. Far too long. You buy it and think "wow, it's big, I've got a universal reference now." And if you're looking for a pedantic list of distinctions between UNIXes, maybe you have a reference. But if you're looking for that, just read the man pages! The good programming books are the short ones that guide you into your environment--<a href="http://cm.bell-labs.com/cm/cs/cbook/">The C Programming Language</a>; <a href="http://cm.bell-labs.com/cm/cs/upe/">The Unix Programming Environment</a>. Big unenlightening reference tomes of APIs are wastes of paper: the internet is constantly changing. Read the <a href="http://www.ietf.org/rfc.html">RFC</a>' s. That's how you learn how the internet works.
Don't get me wrong. Stevens wrote some good books. APUE is a pretty solid reference (though also <i>too big</i>). TCP/IP Illustrated vol 1 is a really good text for conveying the ideas of networking and the internet protocol -- how they really work. But this series: I don't see it being enlightening to anyone.
philcrissman.com.
More reviews of this book.
Stevens ain't dead. The first rule to eternal life is you have to die.
Stevens will forever live. the first step to eternal life is you have to die.