The Connection NCPs allow a client and a server to create, maintain, and destroy a service connection. Some of the requests in this section allow a client and server to interact reliably when using an unreliable (connectionless) datagram service to communicate. The following discussion explains how a client and server interact in an unreliable messaging environment; when reliable message-switching network interfaces are used, much of this connection maintenance becomes unnecessary.
The protocols invoked when using an unreliable message interface are straightforward. When the file server receives a Create Service Connection request, it checks its current list of service connections. If the server already has a connection with the client issuing the request, that connection is reinitialized to a startup state and reused.
When any other service request arrives, the server first determines whether the request sequence number matches the sequence number of the preceding service response message. (The server always keeps a copy of the service response that it most recently sent to each client it is servicing.) If the sequence numbers do not match, the service request is processed to generate a new service response message, and the old service response is replaced. This newly created response message is then sent to the client.
With an unreliable message interface, the client must retry a given service request until it either receives the corresponding service response or until (in its judgment) the file server or the connecting network has failed. The client must retry if a service message is lost enroute from the client to the server, or the service response is lost enroute from the server to the client. The client must determine what a "reasonable" amount of time is for waiting between retries; this timeout period must allow time for a round-trip message exchange and request processing. One way to determine the timeout period is for the client to maintain a weighted average of the times required by previous requests it has made.
Because the time required to service a message may vary, depending on the request type and the server's workload, it is possible for a server to receive a duplicate of the request it is currently servicing. This event signals to the server that the client's timeout has expired. In such a case, the server may reply to the client with a special Request Being Processed message that informs the client that its request has been received by the server and is being acted upon. When a client receives the Request Being Processed message, it must reset its timeout and retry counters and resume waiting for its actual service response message. If the service response does not arrive before the client's timeout expires, the client must repeat the service request to safeguard against the possibility of a lost server response. If the server is still servicing the request, it will respond with yet another Request Being Processed message. In this way, the server can cause a client to wait indefinitely until the client's request has been processed, but the client receives continuing assurances that the communications link is functioning and the server is alive.
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (23) byte 7 SubFuncStrucLen (2) word (Hi-Lo) 9 SubFunction (29) byte 10 RequestCode byte
Reply Format
Offset Content Type (reply header)
Completion Code
0 0x00 Successful 122 0x7A Connection Already Temporary 123 0x7B Connection Already Logged In 124 0x7C Connection Not Authenticated 224 0xE0 No Login Connections Available 251 0xFB Unknown Request 253 0xFD Bad Station Number
Remarks
Values for the request code include the following:
0 Change logged-in to temporary authenticated.
1 Change temporary authenticated to logged-in.
Other Invalid (ERR_UNKNOWN_REQUEST).
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (23) byte 7 SubFuncLen (5) word (Hi-Lo) 9 SubFunction (254) byte 10 ConnectionNumber long (Lo-Hi)
Reply Format
Offset Content Type (reply header)
Completion Code
0 0x00 Successful 198 0xC6 No Console Rights 253 0xFD Invalid Connection Number
Remarks
This NCP is similar to NCP 23 210, but allows station numbers greater than 256.
This NCP logs out the specified station. Any resources or files the station is using are released and the station's service connection is broken. The station must re-establish a service connection and log in before it can resume work on the file server.
If the calling station lacks supervisor privileges, the No Console Rights completion code is returned and the target station is not affected.
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type 0 RequestType (0x1111) word (Hi-Lo) 2 SequenceNumber (0) byte 3 ConnectionNumber (0xFF) byte 4 TaskNumber (ignored) byte 5 Reserved (ignored) byte 6 RequestCode (ignored) byte
Reply Format
Offset Content Type 0 ReplyType (0x3333) word (Hi-Lo) 2 SequenceNumber (0) byte 3 ConnectionNumber (NewConnectionNumber) byte 4 TaskNumber (0) byte 5 Reserved (0) byte 6 CompletionCode (See below) byte 7 ConnectionStatus (StatusFlags) byte
Completion Code
0 0x00 Successful 255 0xFF Failure
Remarks
This call creates a connection between the server and a client. This call will succeed if the server is still logically up and has service connections available.
If the server already has a connection allocated to the specified client, that connection is reinitialized and reused. The client must set the Connection Number of all subsequent request messages to the Connection Number (New Connection Number) returned by the server in the response message.
In addition, the Sequence Number of the next service request must be set to 1, and the Sequence Number field of each succeeding request must be set to 1 plus the Sequence Number of the previous successful request message.
Bits 2 and 4 of the reply's Connection Status field must be checked by the client. Bit 2 is set if the server has no further connections available. Bit 4 is set if the server has been taken down. The Connection Status field should be checked by the client each time that client receives a service response.
The server can receive a Create Service Connection request in three circumstances:
When a station makes an initial request to create a service connection
When a station has not yet received a response to a previous request to create a service connection
When a station has not destroyed a previously created service connection.
In the first case, the server does not have a connection allocated to the station. The server services the request by creating a connection and returning a response that contains the new Connection Number.
In the second case, the server may be in the process of servicing the request, or the server may have already completed servicing the request and returned the response. The station, however, has probably timed out waiting for the response and repeated the request to create a service connection. Since the server knows it has already created the connection, it sends back a response with the same information as the previous response. The server could ignore a duplicate request to create a service connection, but the original response may have been lost, so it is important that a station receive a response to all Create Service Connection requests.
In the third case, a station that has already created a service connection does not destroy the connection conventionally (using the Destroy Service Connection request). Examples of this are a station's being rebooted or powered off. If a station is rebooted and subsequently sends a Create Service Connection request, the server reuses the previous connection number (if the server has not already relinquished the connection).
The server detects whether a station is still using a connection by implementing a watchdog process. The watchdog process is awakened periodically by the server process to check the activity of the current connections. If there are connections that show no activity during the period, then the watchdog process attempts to query those stations in a peer-to-peer fashion. With NetWare's watchdog implementation, an IPX packet that requests a simple response is sent to each of the apparently inactive stations. If a station is still using the connection, the station responds appropriately and the connection remains valid. If a negative response or no response is received by the server, the server reinitializes the connection number and makes it available again to any station.
A Connection Number is simply an index to a table maintained by the server. The table contains, among other things, the unique node address of each station for which a connection is allocated and the socket on which the station is listening for service response packets. Other special-purpose sockets are opened by a station when it creates a service connection. These special-purpose sockets, which include the socket on which a station listens for watchdog packets, are numbered sequentially after the socket dedicated for service response packets. The number of the socket dedicated to listening for watchdog packets is one plus the number of the socket listening for service responses. The packet structure of the watchdog packet is as follows:
Offset Contents Type 0 Header IPXPacketHeader 30 PacketSlot byte 31 SignatureChar byte
The server sets up the Header so that the packet will be sent to the station in question. Packet Slot is set to the Connection Number; Signature is set to a ? (question mark). If the station that receives the packet must keep the connection contained in Packet Slot, the station sets up a similar response packet to return to the server. The station sets the Signature Char to a Y (for Yes), sets Packet Slot to the connection number, and sets up the Header so that the response packet will be sent to the server. When the watchdog process receives this packet it will not relinquish the corresponding connection.
See Also
Destroy Service Connection (0x5555 0 --)
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type 0 RequestType (0x5555) word (Hi-Lo) 2 SequenceNumber (LastSequence+1) byte 3 ConnectionNumber (ServiceConnection) byte 4 TaskNumber (ignored) byte 5 Reserved (ignored) byte 6 RequestCode (ignored) byte
Reply Format
Offset Content Type 0 ReplyType (0x3333) word (Hi-Lo) 2 SequenceNumber (RequestSequenceNumber) byte 3 ConnectionNumber (ServiceConnection) byte 4 TaskNumber (ClientTaskNumber) byte 5 Reserved (0) byte 6 CompletionCode (see below) byte 7 ConnectionStatus (StatusFlags) byte
Completion Code
0 0x00 Successful 255 0xFF Failure
Remarks
This call causes a server to destroy the specified connection (Connection Number) between the server and the client issuing the request. If successful, the connection slot is reinitialized or made available to clients who subsequently request a service connection. If the call fails (because the server has no such connection, or because the specified connection is being used by a client other than the client issuing the request), the server does not reinitialize the connection, but it still sends a service response to the requesting client.
The server is required to send a service response because this service request could be a retransmission of a former request already received and acted upon by the server. If the server's former response was lost in its route to the previous client, the server could have already granted the connection to a new client by the time the old client retries the request.
See Also
Create Service Connection (0x1111 -- --)
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (24) byte
Reply Format
Offset Content Type (reply header)
Completion Code
0 0x00 Successful
Remarks
This call allows a client to inform the server that one of its tasks has finished execution. The server will then close any active files, unlock any locked byte ranges, and perform the required clean-up for any file server resources that the indicated task has been using. The server does not assume any hierarchical relationships between a client's tasks; if such a relationship exists, the client must ensure that this call is made for each affected task in the appropriate order.
If Task Number is set to 0, all the client's tasks have ceased execution and a general "end of job" clean-up should be performed.
| v2.x | v3.x | v4.x | v5.x |
Request
Offset Content Type (request header) 6 FunctionCode (97) byte 7 ProposedMaxSize word (Hi-Lo) 9 SecurityFlag byte
Reply
Offset Content Type (reply header) 8 AcceptedMaxSize word (Hi-Lo) 10 EchoSocket word (Hi-Lo) 12 SecurityFlag byte
Completion Code
0x00 Successful (SecurityFlag contains necessary information) nonzero NCP 97 not supported
Remarks
The AcceptedMaxSize parameter will contain the smallest of the following variables:
The EchoSocket Parameter can be used to hold ECHO packets.
The SecurityFlag parameter in the request packet should contain bits appropriate according to the following bit definitions:
| ChecksummingRequestedBit | 00000001b |
| SignatureRequestedBit | 00000010b |
| CompletSignaturesRequestedBit | 00000100b |
| EncryptionRequestedBit | 00001000b |
| LargeInternetPacketDisableBit | 10000000b |
In the reply packet, the SecurityFlag parameter will be zero if the request packet's SecurityFlag bits are consistent with the servers SignatureLevelRequired parameter
If the request packet's SecurityFlag bits are not consistent with the server's SignatureLevelRequired parameter, the reply packet's SecurityFlag bits will be set to indicate which bits the requester should set on its next issuance of NCP 97.
For example, if the server requires signatures, but the requester issues NCP 97 with SecurityFlag set to 00000000b, (binary zero) the reply packet will contain a security flag set to 00000010b (binary two, which indicates that the server requires signatures). The requester should OR the SecurityFlag of the reply packet with the SecurityFlag in the request packet and re-issue NCP 97.
NOTE: After successfully negotiating the security flags using NCP 97, the requester should store the result of its negotiation in a global variable which indicates whether or not the NCP sesion is subject to MD4 signature verification.
The server can be set to one of the following three checksum states:
No Checksums (Checksums are NOT enabled.)
Allow Checksums (Client can choose to checksum.)
Require Checksums (Server will talk ONLY to clients requesting checksums.)
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (23) byte 7 SubFuncStrucLen (9) word (Hi Lo) 9 SubFuncCode (31) byte 10 ObjectID long (Hi-Lo) 14 SearchConnNumber long (Lo-Hi)
ReplyFormat
Offset Content Type (reply header) 8 ConnListLen word (Lo-Hi) 10 ConnList long[] (Lo-Hi)
CompletionCode
0 0x00 Successful
Remarks
This NCP will get a list of connections via the Object ID.
See Also
Get Object Connection List (0x2222 23 27)
Get Object Connection List (0x2222 23 21)
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (23) byte 7 SubFuncStrucLen (5) word (Hi Lo) 9 SubFuncCode (33) byte 10 ReturnInfoCount long (Lo-hi)
ReplyFormat
Offset Content Type (reply header) 8 ReturnInfoCount long (Lo-Hi) 12 GUID BYTE[ReturnInfoCount] [16] (Lo-Hi)
CompletionCode
0 0x00 Successful
Remarks
This NCP will return a list of GUIDs from the server. The GUID is 16 BYTEs long, and a maximum of 33 can be returned.
| v2.x | v3.x | v4.x | v5.x | v6.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (23) byte 7 SubFuncStrucLen (32) word (Hi Lo) 9 SubFuncCode (34) byte 10 SetMask long (Lo-hi) 14 NCPEncodedStringsBits long (Lo-hi) 18 CodePage long (Lo-hi) 22 Reserved long (Lo-hi)
Reply Format
Offset Content Type (reply header)
CompletionCode
0 0x00 Successful 1 0x01 Not Connected 253 0xFD Bad Station Number
Remarks
This NCP will allow setting the code page of the connection in the connection structure to the code page that the client that initiated the connection is set to. The client can also set the UTF8_NCP_STRINGS_ENABLED (0x1000) bit in the status field of the connection. This indicates to a supporting file system that NCP request path strings will be UTF8 encoded. A volume that supports this feature will have the VIUTF8NCPStringsEnabledBit (0x80) set in it's statusFlagBits field. This can be obtained by using NCP 22 51 (Get Extended Volume Information).
IMPORTANT NOTE: This NCP is avaialable only in Netware v65.sp1 and newer versions, even though it is listed as available in v6.x above.
NOTE: To change the UTF8_NCP_STRINGS_ENABLED status field in the connection, you must set the SetMask field to NCPEncodedStringBit in order for the change to take place. To remove the UTF8_NCP_STRINGS_ENABLED status field from the connection, you must set the SetMask field to NCPEncodedStringBit and set the NCPEncodedStringsBits field to zero before making the NCP request. The NCPEncodedStringsBits field and the CodePage field can both be set in the same request provided that the proper SetMask bits are set.
#define NCPEncodedStringBit 0x00000001
#define ConnectionCodePageBit 0x00000002
| Connection Language Set Mask Bits | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Definition |
| 0 | reserved | |||||||||||||||
| 0 | reserved | |||||||||||||||
| 0 | reserved | |||||||||||||||
| 0 | reserved | |||||||||||||||
| 0 | reserved | |||||||||||||||
| 0 | reserved | |||||||||||||||
| 0 | reserved | |||||||||||||||
| 0 | reserved | |||||||||||||||
| 0 | reserved | |||||||||||||||
| 0 | reserved | |||||||||||||||
| 0 | reserved | |||||||||||||||
| 0 | reserved | |||||||||||||||
| 0 | reserved | |||||||||||||||
| 0 | reserved | |||||||||||||||
| x | Connection Code Page Bit | |||||||||||||||
| x | NCP Encoded Strings Bit | |||||||||||||||
See Also
Enumerate Connection Information From Connection List (0x2222 123 16)
Get Extended Volume Information (0x2222 22 51)
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (23) byte 7 SubFuncStrucLen (5) word (Hi-Lo) 9 SubFunction (26) byte 10 TargetConnection long (Lo-Hi)
Reply Format
Offset Content Type (reply header) 8 NetworkAddressStruct (See below) struct 20 ConnectionType (See below) byte
Completion Code
0 SUCCESSFUL
Remarks
This NCP allows the use of the high connection byte in the Request/Reply header of the packet. The NetworkAddressStruc field contains the Network Address of the target connection number. The following is the definition of the structure:
struct NetworkAddressStruct
{
byte NetworkAddress[4];
byte NetworkNodeAddress[6];
word NetworkSocket; (Hi-Lo)
};
The ConnectionType field describes the type of connection the target has. The different types are as follows:
0 - not in use
2 - NCP
11 - UDP (for IP)
For an IP-only server, the 4-byte IP address is placed into the 4-byte NetworkAddress field of the NetworkAddressStruct, while the NetworkNodeAddress and NetworkSocket fields are left blank.
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (23) byte 7 SubFuncStrucLen (2) word (Hi-Lo) 9 SubFunctionCode (19) byte 10 TargetConnection byte
Reply Format
Offset Content Type (reply header) 8 NetworkAddress byte[12]
Completion Code
0 0x00 Successful 255 0xFF Failure
Remarks
This call returns the physical network address of the client workstation, given the workstation's logical connection number. This call can be used to determine the address of any client that has a connection on the network. Typically this call would precede the setting up of a direct network dialogue between two clients. The format of the Network Address field is network-dependent.
This call is replaced by the NetWare 386 v3.11 call Get Internet Address (0x2222 23 26).
See Also
Get Object Connection List (0x2222 23 21)
Get Internet Address (0x2222 23 26)
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (23) byte 7 SubFuncStrucLen (1) word (Hi-Lo) 9 SubFunctionCode (23) byte
Reply Format
Offset Content Type (reply header) 8 Key byte[8]
Completion Code
0 0x00 Successful 150 0x96 No Allocation Space
Remarks
This request returns an 8-byte password key for the calling station.
See Also
Keyed Object Login (0x2222 23 24)
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (23) byte 7 SubFuncStrucLen (8+ObjectNameLen) word (Hi-Lo) 9 SubFunction (27) byte 10 SearchConnNumber (See below) long (Lo-Hi) 14 ObjectType word (Hi-Lo) 16 ObjectNameLen byte 17 ObjectName byte[ObjectNameLen]
Reply Format
Offset Content Type (reply header) 8 ConnListLen byte 9 ConnNumberList long[ConnListLen] (Lo-Hi)
Completion Code
0 SUCCESSFUL
Remarks
This NCP allows the use of the high connection byte in the Request/Reply header of the packet. See Introduction to Queue NCPs for information on the job structure.
The SearchConnNumber field should be set to 0 initially. Subsequent calls use the highest connection number return in the ConnNumberList.
See Also
Get Object Connection List (old) (0x2222 23 21)
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (23) byte 7 SubFuncStrucLen (4+ObjectNameLen) word (Hi-Lo) 9 SubFunctionCode (21) byte 10 ObjectType word (Hi-Lo) 12 ObjectNameLen byte 13 ObjectName byte[ObjectNameLen]
Reply Format
Offset Content Type (reply header) 8 ListLen byte 9 ConnectionNumberList byte[ListLen]
Completion Code
0 0x00 Successful 150 0x96 Server Out Of Space 240 0xF0 Illegal Wildcard 252 0xFC No Such Object 254 0xFE Directory Locked 255 0xFF Hard Failure
Remarks
This call returns a list of the connection numbers on the server for clients logged in with the specified Object Name and Object Type. If no client is logged in using the specified Object Name and Object Type, the list length returned by the server is set to zero.
This function is the general case of, and replaces the earlier call Get User Connection List (0x2222 23 2).
This call is replaced by the NetWare 386 v3.11 call Get Object Connection List (0x2222 23 27).
See Also
Get Internet Address (0x2222 23 19)
Get User Connection List (0x2222 23 2)
Get Object Connection List (0x2222 23 27)
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (19) byte
Reply Format
Offset Content Type (reply header) 8 StationNumber byte[3]
Completion Code
0 0x00 Successful
Remarks
This request returns the calling station's 3-byte station number.
See Also
Get Station's Logged Info (0x2222 23 22)
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (23) byte 7 SubFuncStrucLen (5) word (Hi-Lo) 9 SubFunction (28) byte 10 TargetConnectionNum long (Lo-Hi)
Reply Format
Offset Content Type (reply header) 8 UniqueUserID long (Hi-Lo) 12 UserType word (Hi-Lo) 14 UserName byte[48] 62 LoginTime byte[7] 69 reserved (0) byte
Completion Code
0 SUCCESSFUL
Remarks
This NCP allows the use of the high connection byte in the Request/Reply header of the packet. See Introduction to Queue NCPs for information on the job structure.
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (23) byte 7 SubFuncStrucLen (2) word (Hi-Lo) 9 SubFunctionCode (22) byte 10 TargetConnectionNumber byte
Reply Format
Offset Content Type (reply header) 8 UniqueUserID long (Hi-Lo) 12 UserType word (Hi-Lo) 14 UserName byte[48] 62 LoginTime byte[7] 69 Reserved byte
Completion Code
0 0x00 Successful 150 0x96 Server Out Of Space 252 0xFC No Such Object 253 0xFD Bad Station Number 254 0xFE Directory Locked 255 0xFF Hard Failure
Remarks
This call returns information about a user at the given connection number. This call may be used by any client.
The Login Time field has the following format:
Byte[0] = Year
Byte[1] = Month
Byte[2] = Day
Byte[3] = Hour
Byte[4] = Minute
Byte[5] = Second
Byte[6] = DayOfWeek
The Year byte contains a value from 0 to 99: values from 80 to 99 correspond to the years 1980-1999, 0 to 79 correspond to the years 2000-2079.
The Month byte contains a value from 1 to 12 corresponding to months January to December.
The Day byte contains a value from 1 to 31, indicating the current day of the month.
The Hour byte contains a value from 0 to 23, indicating the hour of day (0 means 12:00 midnight; 23 means 11:00 p.m., etc.).
The Minute byte contains a value from 0 to 59, indicating the current minute in the hour.
The Second byte contains a value from 0 to 59, indicating the current second in the minute.
The Day Of Week byte contains a value from 0 to 6 corresponding with the weekday (0 for Sunday, 6 for Saturday, etc.).
This call is replaced by the NetWare 386 v3.11 call Get Station's Logged Info (0x2222 23 28).
See Also
Get Station's Logged Info (0x2222 23 28)
Get Object Connection List (0x2222 23 21)
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (23) byte 7 SubFuncStrucLen (1) word (Hi-Lo) 9 SubFunctionCode (5) byte 10 TargetConnectionNumber byte
Reply Format
Offset Content Type (reply header) 8 UserName byte[16] 24 LoginTime byte[7] 31 FullName byte[39] 70 UserID long 74 SecurityEquivalentList long[32] 202 Reserved2 byte[64]
Completion Code
0 0x00 Successful 150 0x96 Server Out Of Space 252 0xFC No Such Object 253 0xFD Bad Station Number 254 0xFE Directory Locked 255 0xFF Hard Failure
Remarks
This call retrieves a station's log record from the network and returns it to the calling station. The log record includes the name and security equivalence list for the station. The caller must be an object of type USER.
The reply message, not including the reply header, is a fixed length of 258 bytes. User Name will contain only the first 15 bytes of the (potentially) 47-byte username; the other characters are lost. The Login Time field is correct. The Full Name field is set to nulls. The User ID is correct. The Security Equivalent List contains the ID numbers of up to 32 objects (users and groups) that are security equivalent to the caller. The Reserved2 field is set to nulls.
This call is maintained only for the sake of compatibility with the logout process of NetWare v4.61 and below. For NetWare v1.0 through v3.1, this call is replaced by the call Get Station's Logged Info (0x2222 23 22). For NetWare 386 v3.11, this call is replaced by Get Station's Logged Info (0x2222 23 28).
The replacement function should be used to get the names of users logged onto a station, and the bindery calls should be used to get information about a user's groups and security information.
See Also
Get Station's Logged Info (0x2222 23 22)
Get Station's Logged Info (0x2222 23 28)
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (23) byte 7 SubFuncStrucLen (2+UserNameLen) word (Hi-Lo) 9 SubFunctionCode (2) byte 10 UserNameLen byte 11 UserName byte[UserNameLen]
Reply Format
Offset Content Type (reply header) 8 ListLen byte 9 ConnectionNumberList byte[ListLen]
Completion Code
0 0x00 Successful 240 0xF0 Illegal Wildcard 150 0x96 Server Out Of Space 252 0xFC No Such Object 254 0xFE Directory Locked 255 0xFF Hard Failure
Remarks
This call returns a list of connection numbers on the server for clients logged in with the specified User Name. If no client is logged in using the specified User Name, the list length returned by the server is set to zero. This is an old NetWare 4.6 call. It is the same as Get Object Connection List (0x2222 23 21), except that it assumes an object of type USER.
See Also
Get Object Connection List (0x2222 23 21)
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (23) byte 7 SubFuncStrucLen (12+ObjectNameLen) word (Hi-Lo) 9 SubFunctionCode (24) byte 10 Key byte[8] 18 ObjectType word (Hi-Lo) 20 ObjectNameLen byte 21 ObjectName byte[ObjectNameLen]
Reply Format
Offset Content Type (reply header)
Completion Code
0 0x00 Successful 150 0x96 No Allocation Space 193 0xC1 No Account Balance 194 0xC2 Credit Limit Exceeded 197 0xC5 Server Login Locked 217 0xD9 Maximum Logins Exceeded 218 0xDA Bad Login Time 219 0xDB Node Address Violation 220 0xDC Account Expired 222 0xDE Bad Password
Remarks
Keyed Object Login logs in the specified bindery object, using the 8-byte key previously assigned to the object.
See Also
Get Login Key (0x2222 23 23)
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (23) byte 7 SubFuncStrucLen * word (Hi-Lo) 9 SubFunctionCode (20) byte 10 ObjectType word (Hi-Lo) 12 ClientNameLen byte 13 ClientName byte[ClientNameLen] 13+ClientNameLen PasswordLen byte 14+ClientNameLen Password byte[PasswordLen]
* SubFuncStrucLen = 5 + ClientNameLen + PasswordLen
Reply Format
Offset Content Type (reply header)
Completion Code
0 0x00 Successful 150 0x96 Server Out Of Space 193 0xC1 No Account Balance 194 0xC2 Credit Limit Exceeded 197 0xC5 Login Lockout 214 0xD6 Unencrypted Password 215 0xD7 Account Bad 217 0xD9 Maximum Logins Exceeded 218 0xDA Bad Log Time 219 0xDB Log Station Error 222 0xDE Bad Password 223 0xDF Old Password 232 0xE8 Write To Group 236 0xEC No Such Set 237 0xED Property Exists 239 0xEF Illegal Name 240 0xF0 Illegal Wildcard 241 0xF1 Bindery Security 242 0xF2 No Object Read 246 0xF6 No Property Delete 251 0xFB No Such Property 252 0xFC No Such Object 254 0xFE Directory Locked 255 0xFF Hard Failure, Failure
Remarks
This call enables a client to identify itself to the file server and thereby gain rights to access certain directories (and hence files) within the file server. Each server keeps a small database of information (called the bindery) about various named objects and their associated properties. File server "users" are one of the types of objects that appear in the bindery. For information concerning bindery objects and functions see the the discussion in the Bindery section of this volume.
Most client objects will identify themselves as Object Type 1, type USER. Other possible object types are identified in the Bindery section.
Receipt of a Login Object request causes the file server to automatically release the client object's previous access privileges, if any.
See Also
Login User (old) (0x2222 23 0)
Logout (0x2222 25 --)
Keyed Object Login (0x2222 23 24)
Get Login Key (0x2222 23 23)
Login Object (0x2222 23 20)
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (23) byte 7 SubFuncStrucLen * word (Hi-Lo) 9 SubFunctionCode (0) byte 10 UserNameLen byte 11 UserName byte[UserNameLen] 11+UserNameLen PasswordLen byte 12+UserNameLen Password byte[PasswordLen]
* SubFuncStrucLen = 3 + UserNameLen + PasswordLen
Reply Format
Offset Content Type (reply header)
Completion Code
0 0x00 Successful 150 0x96 Server Out Of Space 193 0xC1 No Account Balance 194 0xC2 Credit Limit Exceeded 197 0xC5 Login Lockout 215 0xD7 Account Bad 217 0xD9 Maximum Logins Exceeded 218 0xDA Bad Log Time 219 0xDB Log Station Error 222 0xDE Bad Password 223 0xDF Old Password 232 0xE8 Write To Group 236 0xEC No Such Set 237 0xED Property Exists 239 0xEF Illegal Name 240 0xF0 Illegal Wildcard 241 0xF1 Bindery Security 242 0xF2 No Object Read 246 0xF6 No Property Delete 251 0xFB No Such Property 252 0xFC No Such Object 254 0xFE Directory Locked 255 0xFF Hard Failure, Failure
Remarks
This call is still used in the NetWare v2.0a shell, but is no longer used in shells beginning with NetWare v2.1. This is a special form of Login Object (function 23, subfunction 20). The difference in this form is that the object attempting to log in is assumed to be of type USER.
See Also
Logout (0x2222 25 --)
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (25) byte
Reply Format
Offset Content Type (reply header)
Completion Code
0 0x00 Successful
Remarks
This function allows a client to relinquish its current server access privileges without breaking its service connection.
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (33) byte 7 ProposedBufferSize word (Hi-Lo)
Reply Format
Offset Content Type (reply header) 8 AcceptedBufferSize word (Hi-Lo)
Completion Code
0 0x00 Successful
Remarks
This call allows a client to negotiate the buffer size that it will use when sending file read and write requests to the server. Clients are constrained by the buffer size in two ways. First, any file read or file write request may not ask for more data than will fit in the negotiated buffer size. Second, any file read or file write request can not cross a logical byte boundary that corresponds to the negotiated buffer size. These constraints are discussed in detail in the Read From A File (0x2222 72 --) and Write To A File (0x2222 73 --) NCPs under File System NCPs.
The Proposed Buffer Size field contains the buffer size the client wants to use. This buffer size is only a proposed buffer size; in other words, it may be modified by the server. The Accepted Buffer Size field returned by the server contains the buffer size that the client and the server must actually use for file reading and writing. The Accepted Buffer Size will be less than or equal to the Proposed Buffer Size.
Buffer sizes are constrained to one of the following sizes:
512 bytes (.5 K)
1,024 bytes (1 K)
2,048 bytes (2 K)
4,096 bytes (4 K)
8,192 bytes (8 K)
16,384 bytes (16 K)
32,768 bytes (32 K)
When a service connection is first established, the server assumes a default buffer size of 512 bytes.
See Also
Read From A File (0x2222 72 --) (in File System NCPs section)
Write To A File (0x2222 73 --) (in File System NCPs section)
| v2.x | v3.x | v4.x | v5.x |
Reply Format
Offset Content Type 0 ReplyType (0x9999) word (Hi-Lo) 2 SequenceNumber (N/A) byte 3 ConnectionNumber (ConnectionNumber) byte 4 TaskNumber (TaskNumber) byte 5 Reserved (N/A) byte 6 CompletionCode (N/A) byte 7 ConnectionStatus (N/A) byte
Remarks
The file server returns this message when it receives a duplicate service request while the original request is still being processed. This is a signal to the client that the service is currently being processed. This message can be the response to any service request made by the client. If a client receives this request, it must reset its timeout and retry counters and continue to wait for the actual service reply to arrive from the server. If the service reply does not arrive before the timeout counter expires, the client should repeat the request.
If the server and the client use a guaranteed delivery message protocol (such as SPX) to communicate, this message does not need to be returned to the caller.
NOTE:
This Request Being Processed message is not a request message.
See Also
Request Processed (0x3333 -- --)
| v2.x | v3.x | v4.x | v5.x |
Reply Format
Offset Content Type 0 ReplyType (0x3333) word (Hi-Lo) 2 SequenceNumber (RequestSequenceNumber) byte 3 ConnectionNumber (ServiceConnection) byte 4 TaskNumber (ClientTaskNumber) byte 5 Reserved (0) byte 6 CompletionCode (see below) byte 7 ConnectionStatus (StatusFlags) byte
Remarks
The file server returns this message to a client when the server has completed servicing a request. The Reply Format shown above is valid for all functions except Create Service Connection and Destroy Service Connection.
The Sequence Number, Connection Number, and Task Number fields will match the request fields by the same name for the corresponding request.
The Completion Code field should be checked for all replies; a nonzero value indicates that an error occurred while the client's request was being processed by the file server.
The Connection Status field contains the following bits of information:
| Bit 0 | Set if the client's request contained a bad service connection |
| Bit 2 | Set if the client requested a service connection and the file server has no further connections available |
| Bit 4 | Set if the file server is down |
| Bit 6 | Set if the file server is holding a broadcast message for the client |
The Connection Status field should be checked by the client each time a service response ("Request Processed" or "Request Being Processed") message is received. If the Server Down bit is set, the client knows that the service connection has been terminated.
NOTE: This Request Processed message is not a request message.
See Also
Request Being Processed (0x9999 -- --)
| v2.x | v3.x | v4.x | v5.x |
Request Format
Offset Content Type (request header) 6 FunctionCode (23) byte 7 SubFunctionLen (5) word (Hi-Lo) 9 SubFunctionCode (30) byte 10 NumberOfMinutesToDelay long (Lo-Hi)
Reply Format
Offset Content Type (reply header)
Completion Code
0 0x00 Successful 1 0x01 Invalid Number of Minutes to Delay
Remarks
This NCP allows a connection to specify the watchdog delay interval. This interval is the time the server delays before the watchdog begins checking to see if the connection is still active. By setting the watchdog delay interval, a connection can power down for up to 2 weeks and still maintain its connection with the server. A connection can only delay watchdog packets for itself.
The NumberOfMinutesToDelay parameter takes the following values:
| 0 minutes | Resets the connection to the default. |
| 1 to 20,199 minutes | Specifies the amount of time to delay the watchdog packets. (1 minute to approximately 2 weeks) |