![]() |
Welcome to ftp.vim.org,
Hosted by ftp.nluug.nl Current directory: /networking/samba/smblib/ |
Contents of README: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! |
Name Last modified Size
Parent Directory -
README 30-May-1996 04:45 4.9K
smblib-0.10.tar.gz 29-May-1996 09:04 372K
smblib-0.11.tar.gz 31-May-1996 17:24 379K
smblib-0.20.tar.Z 28-Jun-1996 09:32 571K
smblib-0.30.tar.gz 31-Jul-1996 08:46 457K
smblib-0.31.tar.gz 20-Aug-1996 09:51 458K
smblib-0.40.tar.gz 22-Aug-1996 07:25 126K
smblib-0.50.tar.gz 18-Sep-1996 08:39 72K
NLUUG - Open Systems. Open Standards
Become a member
and get discounts on conferences and more, see the NLUUG website!