I have put up the file

     ftp://samba.anu.edu.au/pub/samba/smblib01.tar.gz

which contains the first version of Richard's smblib. He is planning to 
upload another version by the end of the week with better functionality 
including the ability to do a tree connection.

Following is Richard's annouce which I have already posted to the samba 
list, which will hopefully kick off the discussion.

--
 Dan Shearer                            email: Dan.Shearer@UniSA.edu.au
 Information Technology Unit            Phone: +61 8 302 3479
 University of South Australia          Fax  : +61 8 302 3385


===================================================

SMBlib Introductory Message.

INTRODUCTION

I have released some code that I have called SMBlib. It was written over a 
period of time to help me understand the SMB protocol more than I did, which 
wasn't very much. As it happens, I have found even more things that I do not 
understand:-).

I have had approval from my manager at Digital Equipment to post this code
(with disclaimers that there is no support and that Digital is not liable,
so I used the GPL) as example code that may not be useful to anyone :-)

When I started writing it, I wanted to allow for the possibility of SMB being 
implemented over multiple protocols, not just IP, and have tried not to embed 
too many IPisms in the code, but this may be just an artifact of there being so 
little actually implemented.

WHAT IT IS AND WHAT IT DOES
---------------------------

Version 0.1 of SMBlib consists of SMBlib code and NetBIOS over TCP/IP code 
(which I call RFCNB) implemented to RFC1002. It includes simple test programs 
that I use to test the functionality. 

RFCNB can get a connection to a server and send an receive messages, although 
the test probram only tests the establishment of connections. I infer that it 
can send an receive messages because the SMBlib test program can send and 
receive SMBs (and because I wrote the functionality).

I could not find any SESSION DISCONNECT protocol in RFC1002 (perhaps I can't 
read :-), so I have assumed that one just drops the connection to terminate a 
session.

The SMBlib portion contains code that can establish a connection to a server, 
negotiate a protocol, and set up a tree connection. At this stage the only 
protocol that it can negotiate is the Core Protocol (PC NETWORK PROGRAM 1.0)
and it has only been tested getting a tree connection to a Windows 95 PC.

WHERE TO GO FROM HERE
---------------------

If I were implementing a package that was intended to be generally useful, I 
would probably want to look very carefully at the interface that SMBlib 
provides.

Initially, after discussions with Andrew Tridgell, I focussed on the idea of a 
set of functions, but these, it seems to me now, were thought of without good 
consideration of the client programs that might want to use the functions. 

Setting out the functions and then the problems I now see may help to explain 
why I am concerned that the interface should be very carefully designed.

The functions we (Andrew and I) envisioned/envisaged were:

  Connect - This would take a service like \\fred\tree and would set up a 
connection and return a handle

  Open - would take a connection handle and a file and open it on the server, 
returning a file handle

  Close - would close the file

  Read - would take a file handle and read from the file

  Write - would take a file handle and some data and write to the file

  Disconnect - Would disconnect from the server

  A bunch of other routines would be available to do things that SMB allows you 
to do.

The problem I forsee is that of what functionality to place where. Should the 
client application have to build a file system model out of the primitives that 
SMBlib provides, or should it see one presented by SMBlib. Should the client 
application have to present <connection, file path> pairs to SMBlib, or should 
it be able to present <file paths> to SMBlib and have SMBlib resolve that to a 
connection?

A solution to this problem might be for some people to explore client 
implementation issues so that the interface can be well designed up front.

A number of other issues come to mind that relate to the maintainability of the 
code and what sort of structure should be used. In RFCNB I have tried to 
separate out interface related definitions from implementation related 
definitions, but this has not been as cleanly done in the SMBlib code itself. 

I am also not a make guru so my makefiles are primitive and there is quite a but 
that is not implemented.

However, I hope that someone finds the code useful as a guide.

Regards
--------
Richard Sharpe,  sharpe@nmesis.enet.dec.com,  Ph: 61-8-235-7237,  FAX: ...-7299
Digital Equipment Corporation, 139 Frome St, Adelaide 5001, South Australia, OZ
* I have children to keep me poor in a monetary sense, but rich in so many    *
* other ways!                                                                 *
All opinions are those of the author, not of Digital Equipment!