Implementing CIFS
It is one thing to be able to use Samba, Windows, and the Common Internet File System (CIFS) protocol. It is another thing entirely to understand CIFS with sufficient depth to begin coding using it. This is where Christopher Hertel's Implementing CIFS begins.
This thick book (over 600 pages) begins with a history of NetBIOS in the DOS era. It quickly progresses to NetBIOS over TCP/IP (which evolved into the current CIFS protocol). Hertel documents the beginnings of quirks that will last throughout the life of the protocol. There is an RFC that was proposed in 1987, but many vendors have added extensions to this. (It might surprise you to learn that Samba has added extensions, which are covered in Chapter 24).
After the basic overview, he quickly dives into real coding of an actual (though simple) implementation. This will be his style for the rest of the book (except for humorous asides now and then). An aspect of the protocol, such as Name Resolution, will be explained in some detail, and then expounded in actual code (and in a few cases pseudocode).
The detail is good but not overwhelming. Some people (with names like Jerry Carter or Andrew Tridgell) will want more depth than this book provides, but for with a protocol as varied as CIFS, choices have to be made. As the Samba website mentions, this book is written in "Geekish." The book covers aspects of older and newer SMB/CIFS implementations, including a description of the NTLM2 challenge/auth system.
One thing that should be noted is that the code examples work, but as the author points out, they usually have little or no error handling. This is common to many books, but it is something to remember.
Now, should you get this book? If you're just a user, you probably don't need it. But if you've ever wished you could understand the Samba technical mailing list, or wanted to know why it takes up to 15 minutes to see a new machine, then you'll enjoy this book. If you want to utilize CIFS in any manner (even if just implementing Samba for clients), I'd highly recommend reading this. It will help you to understand what is going on on your network, even if you're not writing the code yourself. And if you want to be a Samba coder, it is required reading.
What didn't I like? I first read the book in an airport, and found that it relies heavily on having access to a computer. I would have preferred more explanations of code fragments than was given. However, this is a minor issue; most people who are implementing CIFS will be using a computer! I was also left with a desire for more information, but the large Appendix D along with many sources recommended provide for further study.
As a bonus, Appendix A tells you how to make a good cup of Earl Grey tea! That alone to some would be worth the price of admission.
You can purchase Implementing CIFS from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
And networking technologies have proven to be a letdown to what I was taught in early years of school.
I remember being told that we would have clusters of machines that form a large virtual machine that can multitask using the advantages of each machine. Then when processes needed it, the entire force of the machines could be used.
It was essentially a Mainframe with Beowulf clustering as the power behind the mainframe. I listened to so many unique possibilities with this, but now we have reality and I guess that in the 90's, we could not have guessed what we would be doing just 5-8 years later with computers.
I welcome books that give basics to how protocols evolved and how a person's vision of the future was modified over and over to come up with a new vision for the future to be modified again.
Standing on the edge of Tribal's PowWow, who would have guessed that the vision then would take 5 years to be rerealized again by MSN and Yahoo chats?
The neighborhood is not a neighborhood at all, but more like a grid where communication is not me walking next door to say hello, but me calling up my friend on the other side of town and attempting to move his house next to mine.
SP --- Off Topic and Fine with it.
> For what purpose?
Oh, the usual scripting language reasons: easier to program, easier to debug, reduces dangers of stack smashing and suchlike... all that.
> Ruby is an esoteric language that
> hardly anyone uses and less people will
> use as the years goes on
Ruby is a general purpose language that lots of people use and it will continue to grow in popularity.
There, now we've both made assertions. So where do we go from here?
The Army reading list