Index of /archives/net/samba/smblib
Name Last modified Size Description
Parent Directory -
README 1996-05-30 11:45 4.9K
smblib-0.50.tar.gz 1996-09-18 15:39 72K
smblib-0.40.tar.gz 1996-08-22 14:25 126K
smblib-0.10.tar.gz 1996-05-29 16:04 372K
smblib-0.11.tar.gz 1996-06-01 00:24 379K
smblib-0.30.tar.gz 1996-07-31 15:46 457K
smblib-0.31.tar.gz 1996-08-20 16:51 458K
smblib-0.20.tar.Z 1996-06-28 16:32 571K
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!