 |
Description  |
|
|
FIELD OF
THE INVENTION
This invention relates to the field of networked computer systems and specifically to a method and means for networking a variety of computer systems, regardless of local operating systems and file structures.
BACKGROUND OF THE INVENTION
Computer networks have been developed to allow files to be shared among a number of remote users or clients. In the past, computer networks were designed to support single computer types with a limited range of file systems. In prior systems, a
dedicated file server is required for each type of computer. Recently, several types of computer systems have appeared on the market, each of which have file systems which are not compatible with other systems. As many alternate computer systems now
coexist in many office environments, it is highly desirable to provide a method and means for allowing these systems to share files over a computer network.
One approach to networking diverse computer systems is to provide discrete file servers for each type of computer in the system. The discrete file servers may then be coupled through a device which translates the network protocol of one network
into the protocol of another network. This approach requires detailed knowledge of the protocols of both networks. In addition, since file requests are routed through two separate file servers, system performance is reduced.
Another approach to networking diverse computer systems is to provide a single file server and a protocol-to-protocol converter for each foreign client in the system. For example, one common network manufactured by Novell, employs a feature
referred to as a "Service Protocol Gateway," or SPG, as part of the overall architecture. The SPG translates the file server protocol of a remote user or client system to the file server protocol of the native file server. This approach has a
considerable performance degradation since it also requires that the native protocol be processed. In other words, this approach requires placing a gateway between an existing file server and a foreign client or file server. The gateway performs a
translation between the file server protocols of the respective systems. Unfortunately, this method often requires modification of the file servers involved, especially if any significant level of integration is to be achieved.
Still another approach to networking computers involves teaching a file server about an alternate file system by adding knowledge about a particular file server protocol to an existing file server. For example, an IBMPC can be accessed by
clients of an Apple LocalTalk network if the IBM-PC is running Apple's network protocol (LocalTalk) and Apple server software (AppleShare). Unfortunately, this method offers no integration of network services. For example, this method allows
integration of a foreign client into an existing network but does not allow the foreign client any access to its own user interface or network resources. The foreign client is forced to use the environment of the network it is joining.
The present invention overcomes the above problems by providing a method and means for integration of multiple networks with varying file systems while allowing each client to retain its own native environment in a manner which is totally
transparent to users. The present invention also allows many foreign server types to coexist on a single integrated file server while eliminating server-to-server translations, thus improving performance. In addition, the present invention allows a
central server to perform network management functions on foreign servers as well as allowing foreign file servers to be added to the system without modifying the central file server.
SUMMARY AND OBJECTS OF THE INVENTION
In summary, the present invention comprises a method and means for networking any type of computer system regardless of the local operating systems and file structures. In other words, the present invention allows multiple client types to access
the file system of a central file server. In operation, a foreign file server provides file services to clients which are not recognized by a central file server. The file service requests of clients of a foreign server are directly translated into
file service requests in a format recognized by the native file system of the central server without routing the file service requests through the central server. For each file service request, the central server is advised of activities of foreign file
servers through a communications mechanism implemented in a series of APIs. The APIs are used to advise the central server of foreign server activities, and are not used to request file services. File services, such as opening and closing files,
setinfo and getinfo are performed directly by a file system driver resident in the foreign file server.
Accordingly, it is an object of the present invention to provide a method and means for networking computers having varying file architectures.
It is another object of the present invention to allow multiple file servers to share file resources regardless of the file structures used therewith.
It is another object of the present invention to provide a method and means for providing a networked computer system wherein foreign file servers may be added to the system without modifying the central server.
It is yet another object of the present invention to allow a central server to service multiple client types.
It is still another object of the present invention to improve the speed and performance in a networked computer system having a number of diverse client types and file systems.
It is another object of the present invention to provide a method and system to allow a single file server to support a plurality of logical server types.
BRIEF DESCRIPTION OF THE DRAWINGS
These and other objects may be fully appreciated through the description below and the accompanying drawings in which:
FIG. 1A is a diagram showing the improved distributed processing system of the present invention.
FIG. 1B is a diagram showing the central server table structure used to record activities of foreign file servers.
FIGS. 2A to 2C are flow diagrams detailing the operation of the I.sub.-- NetServerRegister API.
FIGS. 3A and 3B are flow diagrams of the I.sub.-- NetServerDeregister API.
FIGS. 4A and 4B are flow diagrams of the I.sub.-- NetSessionEntryMake API.
FIGS. 5A and 5B are flow diagrams of the I.sub.-- NetSessionEntryClear API, which is invoked to terminate a session entry in a data structure in a foreign server and to notify the central file server that a session has been terminated.
FIGS. 6A to 6C are flow diagrams detailing the operation of the NetSessionEntrySetInfo API, which is invoked to set information about a session.
FIGS. 7A and 7B are flow diagrams detailing the operation of the NetSessionEntryGetInfo API, which is invoked to get information about a session.
FIGS. 8A and 8D are flow diagrams of the NetConnectionEntryMake API, which is invoked to initialize a new connection entry in a data structure in the foreign server and to notify the central server that a new connection has been created.
FIGS. 9A and 9B are flow diagrams of the NetConnectionEntryClear API, which is invoked to terminate a connection entry in a data structure in a foreign server and to notify the central file server that a connection has been terminated.
FIGS. 10A to 10C are flow diagrams detailing the operation of the I.sub.-- NetConnectionEntrySetInfo API of the present invention.
FIGS. 11A and 11B are flow diagrams of the I.sub.-- NetConnectionEntryGetInfo API of the present invention.
FIGS. 12A to 12C are flow diagrams of the I.sub.-- NetFileEntryMake API of the present invention.
FIGS. 13A and 13B are flow diagrams of the I.sub.-- NetFileEntryClear API of the present invention.
FIGS. 14A to 14C are flow diagrams of the I.sub.-- NetFileEntrySetInfo API of the present invention.
FIGS. 15A to 15B are flow diagrams of the I.sub.-- NetFileEntryGetInfo API of the present invention.
FIG. 16 is a flow diagram of the clear/save function called by various APIs of the present invention.
FIG. 17 is a flow diagram of the allocate function called by various APIs of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
Referring now to FIG. 1A, a diagram of the improved distributed computer system of the present invention is shown. The present invention is adapted to allow the files resident in a central server to be accessed and modified by not only central
file server clients, but by clients of foreign file servers as well. In addition, the present invention provides a method and means for integrating any number of file servers, regardless of the operating system and file structures used with each server. The system 100 comprises a central file server 102, which is coupled to a file system 104. The central file server 102 and file system 104 are adapted to provide file services to a plurality of clients 106, 108. Clients are coupled to the file server
102 through local area network (LAN) communication lines 110. In the preferred practice of the present invention, clients request file services from the central server 102 by sending requests in the form of server message blocks (SMBs) in accordance
with the SMB protocol developed by Microsoft, IBM and Intel. Similarly, the central file server 102 responds to file service request SMBs with SMBs which mirror the request SMBs and which may contain the file data requested by a client. The SMB network
protocol is described in a document entitled Microsoft Networks/Open Net File Sharing Protocol V 1.9, 1987, available from Microsoft Corporation, One Microsoft Way, Redmond, Wash. While the system 100 is shown with two clients coupled to central file
server 102, those skilled in the art will readily appreciate that virtually any number of clients could be coupled to the central file server 102. While the present invention is illustrated as employing a central server which is adapted for use with the
SMB protocol, those skilled in the art will appreciate that the principles of the present invention may be used with virtually any network protocol.
In its simplest form, the central server 102 may be thought of as comprising a transport 112, a system kernel 114 and a server module 116. The transport 112 interfaces the network communication lines 110 to the kernel 114 and server module 116.
The transport 112 moves data on to or off of network communication lines 110. As in other systems, the kernel 114 is responsible for communicating with the file system 104 and processing file service requests. The server module 116 receives and
interprets network file requests and communicates them to kernel 114. The server module 116 also formats and assembles network response messages. For example, in operation, a client may wish to open a file. The client transmits an open file SMB to the
central server 102 where it is intercepted by transport 112. The, transport 112 routes the open file SMB to server module 116. The server module then unpacks the SMB request and converts it to a conventional operating system file request, such as
DosOpen, in the well-known OS/2 operating system. The file system request is then routed to the file system 104 through kernel 114. Once the requested file operation is completed, the kernel 114 routes the requested data (which includes a file handle
in the case of a DosOpen) to the server module which packages the requested data in the form of a response SMB. The response SMB is then routed to the requesting client through the transport 112.
The present invention is also adapted to support file service requests from foreign file servers for files which are resident on the central file server 102. While the system 100 is illustrated with a single foreign server 118, the present
invention contemplates the use of numerous foreign file servers, and there is virtually no limit to the number of foreign servers which could be supported in accordance with the techniques of the present invention. While the foreign server 118 may be
implemented as an independent system, it is contemplated that the foreign server 118 may be integrated with the central file server 102 and the servers 102, 118 wherein the entire system may be implemented within a single process 120 and resident on a
single computer system. In its simplest form, the server 118 may be thought of as comprising a transport 122, a kernel 124 and a server module 126, whose functions are identical to transport 112, kernel 114 and server module 116, respectively. It is
contemplated that the foreign server 118 may maintain its own file system 128 or share file system 104 and support its own client base as indicated by clients 132, 134 and 136. While in the system 100, the central server 102 may be adapted to service
clients operating under the MS-DOS or OS/2 operating systems and using file systems compatible therewith, the foreign file server 118 may be adapted to service clients using a completely different operating system and file system, such as the operating
system and file system used with Apple Macintosh computers. For example, the foreign server 118 may be configured to support the Apple LocalTalk and AppleShare local area network protocols.
The present invention provides an efficient method and means for the clients of the foreign file server 118 to have complete and transparent access to files maintained in file system 104. When performing foreign network operations locally,
assuming the file server 118 were adapted for use with Macintosh type clients, a client would generate a network file request in the form of an Apple Filing Protocol request (AFP). The Apple Filing Protocol is well known. As with the central file
server 112, the request AFP is routed to the server module 126, which disassembles the request AFP and routes the file system request to kernel 124. Kernel 124 then instructs the file system 128 to perform the requested file operation. Once the file
operation has been performed, the requested data is routed through the kernel 124 and server module 126 to generate a response AFP. The response AFP is then sent to the requesting client through transport 122.
According to the principles of the present invention, in addition to performing foreign operations locally, the foreign server 118 is adapted to perform file services with file system 104. In prior systems, if a foreign client requests file
services from a network server having an incompatible file system, the file service request is routed to the server module of the incompatible system where it is translated into a form which is recognized by its associated kernel. The kernel then
translates the file system request into a form which is recognized by the incompatible file system. Therefore, file service requests go through two levels of translation when processing file service requests from foreign file servers. The present
invention provides a novel method and means for facilitating file service requests from foreign servers by providing a server module 126 which includes a mapping means 140, which directly converts file service requests from foreign clients 132 to 136
into a form which is recognized by file system 104.
While the present invention provides a novel architecture for distributed computer systems in which the mapping means 140 is only one component, mapping means are a well-known means for converting file protocols. One example of a known mapping
means is the LAN MANAGER NETWARE Server (LMNS) available from Racal-Interlan, which converts Novell Netware file system requests into Microsoft LANManager and OS/2 requests.
The translated file service request is directly communicated to file system 104 through channel 142, thus eliminating the second level of translation required if the file service request is routed through server module 116. In addition, the
present invention contemplates the use of channel 144 to facilitate communication between central server module 116 and foreign server module 126, so that file system functions are provided in a coordinated manner wherein the central server 102 is fully
apprised of the actions of foreign server 118.
For example, the present invention is particularly adapted for use in a multiuser/multitasking environment. In this type of system, files must be protected from multiple users attempting to modify the file simultaneously. If files are not
protected from multiple user modification, users may be working with inconsistent versions of the same file. Therefore, in a multiple user environment, files are temporarily locked when modifications are made by a single user and unlocked when the
modification is complete. In accordance with the principles of the present invention, the foreign server 118 may access the file system 104 directly. Therefore, the central server must be informed which files are opened and locked by foreign server
118. One advantage of the present invention is that the central server can record and display statistics for file operations for the entire system 100.
While files of the file system 104 are being processed by foreign server module 126, the foreign server module 126 calls a number of application program interfaces (APIs) to instruct the central server module 116 as to file service functions
being directly performed on the file system 104. An API may be thought of as a modular unit which performs a known function or procedure. APIs typically employ data structures wherein certain values may be accessed, set and manipulated, and certain
values and/or error codes are often returned by APIs. The central server 116 then responds to server APIs with entry points to dynamic linked library (DLL) APIs to confirm communication between the respective file servers. DLLs are a well-known feature
of the OS/2 operating system and are specific instances of APIs which are available as common resources to any application or other type of executable code. Therefore, system performance is greatly enhanced by allowing direct file system access from
foreign file servers to the central file system 104, and by reducing communication between the central file server and foreign servers to information about the status of files.
While the kernel and server module of the central server are preferably implemented for use with the OS/2 operating system developed by Microsoft, those skilled in the art will appreciate that the present invention may be implemented with
virtually any operating system or combination of operating systems. The present invention is adapted for use with a number of foreign file servers, as indicated by foreign file servers 146 to 152.
In accordance with the teachings of the present invention, the activities of foreign servers are tracked on the central server in the form of tables or internal data structures of the type shown in FIG. 1B. On a high level, the central server
maintains a repository, or table 160, which stores information for each foreign server active in the system. Each instance 162 of foreign server entries in table 160 includes a reference 164 to four tables 166 to 172. Table 166 maintains information
for each session and contains one entry 167 for each session. Table 168 contains one entry 169 for each connection. Table 170 contains one entry 171 for each file, and table 172 contains one entry 173 for each client type supported by the foreign
server. The concept of sessions, connections, files and client types is further discussed below.
The data structure for table entry 162 is set forth below:
__________________________________________________________________________ struct alt.sub.-- srvdata { struct alt.sub.-- srvdata far*asd.sub.-- nextsd; /*Next server in asdfreeq. */ unsigned short asd.sub.-- srv.sub.-- id; /*Offset of entry
in sd asd */ char asd.sub.-- state; /*FREE, ACTIVE, CLOSING etc. */ char asd.sub.-- pad1; char asd.sub.-- dllmod.sub.-- name[MAXPATHLEN]; /*DLL module for AltSrv APIs */ unsigned short asd.sub.-- num.sub.-- cltype; /*Number of client types */
struct client.sub.-- type.sub.-- info far*asd.sub.-- cllist; /* List of client type structs */ unsigned short asd.sub.-- pid; /*ID of registering process */ /*Alt server service stats */ unsigned long asd.sub.-- srv.sub.-- type; /*Type of server */
unsigned short asd.sub.-- num.sub.-- conns; /*Max number of connections */ unsigned short asd.sub.-- num.sub.-- files; /*Max number of open files */ unsigned short asd.sub.-- num.sub.-- sess; /*Max number of sessions */ unsigned short asd.sub.--
cur.sub.-- conns; /*Active connections */ unsigned short asd.sub.-- cur.sub.-- files; /*Currently open files */ unsigned short asd.sub.-- sess; /*Currently active sessions */ unsigned long asd.sub.-- first.sub.-- file; /*Fileid of first open file
*/ Table for sessions, pointer to first free entry in the table and pool of free session entry structures. struct asd.sub.-- sentry far*far*asd.sub.-- sess; struct asd.sub.-- sentry far*far*asd.sub.-- sess1stfree; struct asd.sub.-- sentry
far*far*asd.sub.-- sessfreeq; Table for connections, pointer to first free entry in the table and pool of free connection entry structures. struct asd.sub.-- centry far*far*asd.sub.-- conn; struct asd.sub.-- centry far*far*asd.sub.-- conn1stfree;
struct asd.sub.-- centry far*far*asd.sub.-- connfreeq; Table for files, pointer to first free entry in the table and pool of free file entry structures. struct asd.sub.-- fentry far*far*asd.sub.-- file; struct asd.sub.-- fentry far*far*asd.sub.--
file1stfree; struct asd.sub.-- fentry far*far*asd.sub.-- filefreeq; }; End of alt.sub.-- srvdata The data structure for table entry 167 is set forth below: struct asd.sub.-- sentry { struct asd.sub.-- sentry far*se.sub.-- nextentry;/*Points to next
sess in freeq*/ struct alt.sub.-- srvdata far*se.sub.-- server;/*Points to owning server*/ unsigned short se.sub.-- sessid; /*Contains ID of session*/ char se.sub.-- state; /*FREE, ACTIVE etc.*/ char se.sub.-- pad1; char se.sub.-- cname [CNLEN+1]; /*Comp that setup session*/ char se.sub.-- username [UNLEN+1]; /*User that made session*/ unsigned long se.sub.-- sesstime; /*Time session was established*/ unsigned long se.sub.-- idletime; /*Time last action occurred*/ unsigned long se.sub.--
userflags; unsigned short se.sub.-- userhash; /*Hash value of user name*/ unsigned short se.sub.-- cnhash; unsigned short se.sub.-- numcons; /*Currently active connections*/ unsigned short se.sub.-- numopens; /*Currently open files*/ unsigned
short se.sub.-- numusers; /*Number of logged on users*/ unsigned short se.sub.-- cltype; /*Index to client type table.*/ struct asd.sub.-- fentry far* se.sub.-- openfileq; /*Queue of the open files*/ }; /*End of asd.sub.-- sentry*/ The data
structure for table entry 169 is set forth below: struct asd.sub.-- centry { struct asd.sub.-- centry far *ce.sub.-- nextentry; /*Next struct in free queue.*/ struct alt.sub.-- srvdata far *ce.sub.-- server; /*Points to owing server*/ struct
asd.sub.-- sentry far *ce.sub.-- onwersess; /*Session that setup connection*/ unsigned short ce.sub.-- connid; /*Connection id*/ char ce.sub.-- state; /*FREE, ACTIVE, CLOSING etc.*/ char ce.sub.-- pad1; unsigned short ce.sub.-- conntype; unsigned
short ce.sub.-- openfiles; /*Number of open files*/ unsigned short ce.sub.-- numusers; /*Number of users*/ unsigned long ce.sub.-- conntime; /*Time connected*/ char far* ce.sub.-- username; /*Name of user*/ struct offer far *ce.sub.-- netshare;
/*Offer structure connected to*/ }; /*End of asd.sub.-- centry*/ The data structure for table entry 171 is set forth below: struct asd.sub.-- fentry} struct asd.sub.-- fentry far *fe.sub.-- nextentry; /*Next file struct in queues*/ struct
alt.sub.-- srvdata far *fe.sub.-- server; /*Points to owing server*/ struct asd.sub.-- centry far *fe.sub.-- ownerconn; /*Connection that opened file*/ unsigned long fe.sub.-- fileid;/ /*ID of the file*/ char fe.sub.-- state; /*FREE, ACTIVE
etc.*/ char fe.sub.-- pad1; unsigned short fe.sub.-- permissions; unsigned short fe.sub.-- numlocks; /*Number of locks*/ char far* fe.sub.-- pathname; /*Absolute path and name*/ char far* fe.sub.-- username; /*User that opened the file*/ };
/*End of asd.sub.-- fentry*/ The data structure for table entry 173 is set forth below: Each of the client type structures is defined in server.h to be: struct client.sub.-- type.sub.-- info { char cltype.sub.-- name [CLTYPE.sub.-- LEN+1]; char
cltype.sub.-- pad1; where: cltype.sub.-- name is an ASCIIZ string that contains the client type. cltype.sub.-- pad1 is character used to provide word alignment of the structures.
__________________________________________________________________________
The APIS of the present invention may be divided into four basic classifications: initialization and termination of communications channels, session operations connection operations, and file operations. In addition, the present invention may
employ existing APIs, such as APIs used for resource allocation and sharing, and message operations. Initialization and termination APIs are used to establish communications channels between the central server and foreign file servers. Session APIs
notify the central server of session operations, such as the addition or deletion of sessions, setting session information and getting session information. Connection APIs notify the central server of attempts to access a shared resource by a client. A
connection may be thought of as a particular instance of a client access to a shared resource. Operations which may be performed on a connection by a client include connection establishment, termination, setting of file status and retrieval of file
status. File APIs notify the central server of file operations performed by clients through a foreign server. Such operations can include operations such as file open and file close.
The overall operation of the present invention may be explained as follows. Upon foreign server start-up, the foreign server calls the I.sub.-- NetServerRegister API to register its services with the central server. In the register.sub.--
info.sub.-- 0 data structure passed to the central server, the foreign server specifies a DLL module which contains the APIs used by the central server to communicate with the foreign server. When a client of the foreign server wishes to connect to a
central server resource, the foreign server calls the I.sub.-- NetSessionEntryMake API to establish a session from the specified client to the central server. This session is the parent of later connections and file operations. When the client of the
foreign server wishes to access a central server resource, the foreign server calls the I.sub.-- NetConnectionEntryMake API to notify the central server of the request. Once a session and connection have been established on the central server, the
foreign server services its client's file system requests through use of the file APIs described below. When a client of the foreign server wishes to cease access to a central server resource, the foreign server issues a call to the I.sub.--
NetConnectionEntry Clear API to notify the central server. When all connections of a specific client session have been cleared, the foreign server calls the I.sub.-- NetSessionEntryClear API to notify the central server to break the connection to the
central server resource. When a foreign server wishes to cease operation, it calls the I.sub.-- NetServerDeregister API to terminate its services with the central server. For each API called by the foreign server, the central server responds with a
status code either confirming the operation or indicating an error.
For operations such as central service shutdown initiated by the central server, existing OS/2 local area network APIs and APIs contained within a DLL provided by the foreign server are used to communicate the operations to the foreign server.
These APIs are set forth below: ##SPC1##
It should be noted that the above APIs may be implemented in a variety of ways, which are readily apparent to persons of ordinary skill, depending on foreign server implementation.
In addition to the APIs discussed herein, the present invention is also adapted to invoke existing APIs which are currently available in the Microsoft "LanMan" local area network. A detailed technical description of the Microsoft LanMan local
area network is set forth in a document "LANManager Programmers Reference." An example of an existing API used in the operation of the present invention is the NetServiceControl API used to instruct servers and clients that a network shutdown is about to
occur.
The following external data structures are maintained by the central server in the course of the operation of the present invention.
__________________________________________________________________________ SERVER CATEGORY Structures and Predefined Values The following values will be added in the type of software that the computer is running (list of SV.sub.-- TYPEs) in
server.h: Manifest Value Type of Software SV.sub.-- TYPE.sub.-- AFP 64 Apple Filing Protocol Server SV.sub.-- TYPE.sub.-- NOVELL 128 Novell File Server The following constant will be specified in the netcons.h file: (specifies the length of the
client type string) #define CLTYPE.sub.-- LEN 12 Also the following structure will be defined in server.h: struct register.sub.-- info.sub.-- 0 { unsigned long rg0.sub.-- type; unsigned short rg0.sub.-- max.sub.-- connections; unsigned short
rg0.sub.-- max.sub.-- openfiles; unsigned short rg0.sub.-- max.sub.-- sessions; char far* rg0.sub.-- dllmod.sub.-- name; unsigned short rg0.sub.-- num.sub.-- cltype; where: rg0.sub.-- type tells the type of software the computer is running, defined
in server.h as: Manifest Value Type of Software SV.sub.-- TYPE.sub.-- WORKSTATION 1 Workstation SV.sub.-- TYPE.sub.-- SERVER 2 Server SV.sub.-- TYPE.sub.-- SQLSERVER 4 SQL SV.sub.-- TYPE.sub.-- AFP 64 Apple Filing Protocol Server SV.sub.--
TYPE.sub.-- AFP 64 Apple Filing Protocol Server SV.sub.-- TYPE.sub.-- NOVELL 128 Novell File Server rg0.sub.-- max.sub.-- connections specifies the maximum number of connections that can be made to this server. rg0.sub.-- max.sub.-- openfiles
specifies the maximum number of files open at the same time that this server supports. rg0.sub.-- max.sub.-- sessions specifies the maximum number of sessions at any time for this server. rg0.sub.-- dllmod.sub.-- name is a pointer to an ASCIIZ
string containing the name of the dynamic link module that contains the APIs to be called when adding or deleting a share, closing files and sessions and when sending messages to users. rg0.sub.-- num.sub.-- cltype is an integer specifying the
number of client type structures that follow the register.sub.-- info structure. The number of client structure must be 1 or more. Each of the client type structures is defined in server.h to be: struct client.sub.-- type.sub.-- info { char
cltype.sub.-- name [CLTYPE.sub.-- LEN+1]; char cltype.sub.-- pad1; } where: cltype.sub.-- name is an ASCIIZ string that contains the client type. cltype.sub.-- pad1 is character used to provide word alignment of the structures. There is the need
for communication directed from the central server to the server services. That communication path is through a dynamic link module that the foreign servers provide as follows: AltSrvMessageBufferSend: sends the message in the buffer being passed,
to the user specified. AltSrvMessageFileSend: sends the contents of a file to the specified user. AltSrvSessionDel: deletes the session that the specified user established. AltSrvFileClose: closes the file specified in the parameters being passed. AltSrvShareAdd: adds a share to the list of shares. AltSrvShareDel: deletes the specified share. SESSION CATEGORY Structures and Predefined Values Introduction of level 2 session structure: struct session.sub.-- info.sub.-- 2 { char far
*sesi2.sub.-- cname; char far *sesi2.sub.-- username; unsigned short sesi2.sub.-- num.sub.-- conns; unsigned short sesi2.sub.-- num.sub.-- opens; unsigned short sesi2.sub.-- num.sub.-- users; unsigned long sesi2.sub.-- time; unsigned long
sesi2.sub.-- idle.sub.-- time; unsigned long sesi2.sub.-- user.sub.-- flags; char far* sesi2.sub.-- cltype.sub.-- name; } where: sesi2.sub.-- cname is a pointer to an ASCIIZ string that contains the computername of the Workstation that established
the session. sesi2.sub.-- username points to an ASCIIZ string that containing the name of the user that established the session. sesi2.sub.-- num.sub.-- conns tells how many connections have been made during the session. sesi2.sub.-- num.sub.--
opens tells how many files, devices and pipes have been opened during the session. sesi2.sub.-- num.sub.-- users specifies how many users have made connections via the session. sesi2.sub.-- time specifies the time of the day when the session was
established. sesi2.sub.-- idle.sub.-- time specifies the time of the day the last package was received. sesi2.sub.-- user.sub.-- flags tells how the user established the session. The bit mask for sesi2.sub.-- user.sub.-- flags is defined in shares.h
as follows: Manifest Value Meaning SESS.sub.-- GUEST 1 sesi2.sub.-- username established the session using a GUEST account. SESS.sub.-- NOENCRYPTION 2 sesi2.sub.-- username established the session without using password encryption. sesi2.sub.--
cltype.sub.-- name is a pointer to an ASCIIZ string that specifies the type of client that established the session. __________________________________________________________________________
CONNECTIONS CATEGORY
All data structures and predefined values used by the following APIs have been previously defined in the LANManager Programmers Reference mentioned above.
FILES CATEGORY
All data structures and predefined values used by the following APIs have been previously defined in the LANManager Programmers Reference mentioned above.
The following figures of the drawings describe the operation of the present invention. FIGS. 2A to 2C are flow diagrams of the I.sub.-- NetServerRegister, which is an API used to register the foreign service with the file server of the present
invention. This is the initial call made from a foreign server to the central to instruct the central server that a foreign server requires file services on the central server. Communication between the central server and the foreign server occurs in
three phases:
1. An initial phase wherein the foreign server instructs the central server that its foreign services are available to the central server.
2. An intermediate phase wherein the foreign server processes foreign client requests and reports such actions to the central server.
3. A final stage wherein foreign server notifies central server that its services are no longer available.
The I.sub.-- NetServerRegister API 200 is called to perform the initial phase. This process is invoked to set up any necessary data structures within the central server. The data structures for this API are set forth below:
__________________________________________________________________________ I.sub.-- NetServerRegister (admin, Server) __________________________________________________________________________ This API validates the data being passed in the
buffer and then it will register the server service and will create the entries for the types of clients that the server will serve. #include <netcons.h> #include <server.h> unsigned far pascal I.sub.-- NetServerRegister (level, buf,
buflen, server.sub.-- id) short level; char far* buf; unsigned short buflen; unsigned short far* server.sub.-- id; where: level specifies the level of detail of the structure that contains the information about the server to be registered (the
level must be 0). buf is a pointer to a structure that contains the server information. buflen specifies that length of the buffer. server.sub.-- id is a pointer to an integer. Upon return from this call, this pointer's contents will be an
identification number for this server. This will be used for later reference of the server. NOTE: At least one client type must be specified. If not client types are specified, upon return server.sub.-- id will be 0xFFFF and the result of calling
the API will be ERROR.sub.-- INVALID.sub.-- PARAMETER. Return Codes NERR.sub.-- Success No errors encountered ERROR.sub.-- NETWORK.sub.-- ACCESS.sub.-- DENIED Administrative privileges required ERROR.sub.-- INVALID.sub.-- PARAMETER Invalid
parameter specified ERROR.sub.-- INVALID.sub.-- LEVEL Invalid level parameter NERR.sub.-- NetNotStarted Device driver not installed NERR.sub.-- ServerNotStarted Server service not installed NERR.sub.-- ServiceInstalled Server is already
registered __________________________________________________________________________
The central server uses these data structures for tracking which foreign servers are active and available to foreign clients. In general, the process 200 is used to validate parameters, to determine whether the network is active, to verify that
the caller of the API has authority to use the API, to validate parameter values, to locate central server data in memory, to protect central server data against multiple client access, to perform a requested system function, to unprotect the central
server data and to release access to central server data. If an error is detected at any point in the process, all nonrequested system functions are reversed and the appropriate error code is returned to the caller.
When invoked, the process 200 begins with item 202 which performs error checking on the parameter passed to the central server to determine whether the parameters reference is a legal location within memory. Decision 204 then determines whether
the network is installed and active. If not, a NERR.sub.-- NetNotStarted error code is returned to the caller in termination block 206. If decision 204 determines the network is installed and active, control passes to decision 208, which determines
whether the caller has authority to invoke the API 200. If not, a ERROR.sub.-- NETWORK.sub.-- ACCESS.sub.-- DENIED error code is returned to the caller in termination block 210. If decision 208 determines the caller has authority to proceed in the API
200, control passes to decisions 212, 216, 220, 228 and 232 to validate any parameters passed the API. Decision 212 determines whether the buffer length parameter passed to the API is correct. If not, error NERR.sub.-- BufTooSmall is returned by
termination block 218. Decision 216 determines whether the data structure level of detail is zero. If not, error ERROR.sub.-- INVALID.sub.-- LEVEL is returned by termination block 218. Decision 220 determines whether the pointers stored in the buffer
are pointing to valid positions in memory. If not, ERROR.sub.-- INVALID.sub.-- PARAMETER is returned by termination block 222. Decision 228 then determines whether the name of the DLL module identified in the buffer is valid. A DLL is a dynamic linked
library which is a shared library resource which may be used by any executable file in the system. DLLs are used for two forms of communication:
1. Whenever the foreign server communicates with central server through APIs discussed herein; and
2. Whenever the central server communicates with foreign server, communication is provided through a DLL provided by foreign server.
In the preferred practice of the present invention, the foreign server provides a DLL to the central with known entry points, and is of the form AltSrvXXXYYY, where XXX is the object in which the API acts on and YYY is the operation to be
performed on the object, e.g., file=XXX and close=YYY. This technique allows the central server to receive feedback from the foreign servers as to progress or outcome of the called entry point.
If decision 228 determines the DLL module name is not valid, ERROR.sub.-- INVALID.sub.-- PARAMETER is returned by termination block 230.
Referring now to FIG. 2B, decision 232 determines whether the provided DLL module has the correct entry points. If not, ERROR.sub.-- INVALID.sub.-- PROCNAME is returned by termination block 234. Decision 236 determines whether the caller can
access the central server memory. If not, error NERR.sub.-- ServerNotStarted is returned by termination block 238. Decision 240 determines whether the data structure that contains the entries for the foreign servers can be protected so that multiple
access to the data structure is prohibited. If not, e.g., if the protection mechanism fails, item 242 reverses the accessing of the server segments through an internal API call and NERR.sub.-- InternalError is returned by termination block 244. Loop
245 is invoked to set up any internal data structures, if necessary. Decision 246 determines whether a table for the foreign server entries exists. If not, item 248 allocates a server table. If while allocating a server table, the allocation attempt
fails, an error is returned to the caller and all previous operations are reversed using a clear/free operation. The clear/free operation is discussed in further detail below, in conjunction with FIG. 16. The allocate operation is also discussed in
further detail below, in conjunction with FIG. 17.
Once the server tables are allocated, decision 250 determines whether the foreign server is already registered, i.e., the foreign server is already known to the central server. If so, NERR.sub.-- ServiceInstalled is returned by termination block
252. Decision 254 determines whether sufficient table space is available within the central server to accommodate the registering server. If not, NERR.sub.-- TooManyServers is returned by termination block 256. Items 258-270 then perform the requested
operation, such as allocating and initializing all necessary data structures. For each of the functions performed in items 258-270, if an error is encountered, or if the allocation attempt fails, an error is returned to the caller and all previous
operations are reversed. Those skilled in the art will appreciate that semaphores are a form of mutual exclusion. Item 272 is invoked to release a semaphore to relinquish control of the data structure. Item 274 is invoked to release server segments by
calling an internal API call.
Referring now to FIGS. 3A and 3B, the I.sub.-- NetServerDeregister API 300 notifies the central server that a foreign server is withdrawing services. This notification allows the central server to perform any necessary operations, such as
disposing of any internal data structures and updating any necessary statistics, etc. The data structures used with this API are set forth below:
______________________________________ #include <netcons.h> #include <server.h> unsigned far pascal I.sub.-- NetServerDeregister (server.sub.-- id) unsigned short server.sub. -- id; where: server.sub.-- id is an integer that
specifies the server to deregister from a list of available servers. Return Codes NERR.sub.-- Success No errors encountered ERROR.sub.-- INVALID.sub.-- PARAMETER Invalid para- meter specified NERR.sub.-- NetNotStarted Device driver not
installed NERR.sub.-- ServerNotStarted Server service | | |
