I've sent this mail to the main samba list today - after some more digging I assume that it is better directed to this list (the jCIFS list seems to also be mainly used for user questions). Sorry for crossposting. At least I've corrected some spelling errors since...
-------- Original Message -------- From: David Maurus <[EMAIL PROTECTED]> Subject: [Samba] Prior Art on US Pat. 5,265,261 [=FTP?] To: [EMAIL PROTECTED] As you might be aware, Microsoft explicitly mentions US patents 5,265,261 and 5,437,013 in its new CIFS license. Below is my shot at an analysis of the main claim of pat 5,265,261. Here is a link to patent 5,265,261 [long, might need reassembly when line-wrapped!] http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1='5,265,261'.WKU.&OS=PN/5,265,261&RS=PN/5,265,261 IMHO the described methodology resembles the FTP protocol as published in RFC 959 in October 1985 (there were even earlier versions before - starting at around 1971). I'll dissect the main claim into little pieces and show how they IMHO relate to the FTP protocol (in brackets). I read the main claim as follows: > 1. A computer implemented method in a computer system for > transmitting data from a server computer to a consumer computer > connected by a virtual circuit In plain English: we have a client, a server, a virtual circuit (e.g. a TCP/IP session, like a FTP Control Connection from the client to the server's port 21), and we use this setup to transmit data from the server to the client... > the consumer computer having an application program requesting > a read from the server computer, having a redirector, and having > a transport, the application program having access to a data > buffer allocated by the application program, comprising the steps of: The client runs an application (FTP command line client frontend) requesting a read from the server computer (FTP "GET" command), having subsystems we call "redirector" and "transport" (the latter being a ftp client library). The client application has allocated a data buffer... > allocating and initializing a receive network control block for > directing the transport to store the next data it receives directly > in the data buffer; The client opens a listen socket ["initializing a receive network control block"] (in FTP this would be listening on port 20 for incoming data connections) and tells its "transport" component (ftp client library) to store the next data received directly into the previously allocated buffer. (this is done via a call to the library - further parameters - besides the buffer - will be passed to the lib, as detailed in the following lines) > transmitting from the redirector to the transport a read request > to read data from the server Then the client transmits via the redirector (?) to the transport the read request (by calling a corresponding function in the FTP library that will retrieve a file via the FTP "GET" command) that will tell the server to send some data > and said receive network control block for directing the transport > to store the read data directly in the data buffer, and the client also gives the "transport" component (again, for this exercise, a ftp client library) the socket handle and the allocated data buffer where the data is to be stored directly. > the read request indicating that the read data should be transmitted > without a header; It should be possible to deduct from the read request that the data should be sent without a header (I am not extremely familiar with the FTP protocol, but in FTP this would be the default meaning of the "GET" command, unless other transfer modes or file structures are set, specifically one needs to use "Stream Mode" as transfer mode and "File" as File Structure, which are both the default values according to RFC 959) > in response to the step of transmitting, sending the read request from > the transport to the server computer; the "transport" component sends the read request to the server computer (our library sends "GET filename" to the ftp server via the control connection) > examining and recognizing that the read request indicates that the > read data should be transmitted without a header; and the server - as has been mentioned a lot of times now - can see from the command that it should not send a header with the data > storing the read data in a data block without the header; The server reads the data and stores it in a data block, as requested without header (like any simple ftp server that mallocs some memory and fopens and freads the requested file - there are also no headers involved here) > transferring the data block from the server computer to the transport > in response to the step of sending the read request; Now the datablock is transferred from the server to the client (using the FTP protocol, this would be opening the FTP Data Connection from any port on the server computer e.g. to port of the client computer, and sending the data) > and in response to the read request and the receive network control > block and in response to the step of transferring, storing the data > block directly from the transport into the data buffer. The client (more specifically in my FTP analogy, the ftp client library) subsequently stores the received data in the previously allocated data buffer CONCLUSION: In my eyes this resembles the FTP protocol very closely, not to mention that I cannot see any invention here that any average programmer wouldn't be able to come up with within some hours. The minor nit-picks like "data is transferred WITHOUT header" should not matter IMHO, but I think FTP would even match this. (Disclaimer: IANAL) This is my point of view, I hope I haven't missed something. Best Regards, David Maurus
