- B nodes solicit name information by broadcasting a request.
- P nodes ask the NBNS.
- M nodes broadcast a request. If that does not provide the
desired information, an inquiry is sent to the NBNS.
15.1.3. NAME RELEASE
NetBIOS names may be released explicitly or silently by an end- node.
Silent release typically occurs when an end-node fails or is turned-
off. Most of the mechanisms described below are present to detect
silent name release.
15.1.3.1. EXPLICIT RELEASE
B nodes explicitly release a name by broadcasting a notice.
P nodes send a notification to their NBNS.
M nodes both broadcast a notice and inform their supporting NBNS.
15.1.3.2. NAME LIFETIME AND REFRESH
Names held by an NBNS are given a lifetime during name registration.
The NBNS will consider a name to have been silently released if the
end-node fails to send a name refresh message to the NBNS before the
lifetime expires. A refresh restarts the lifetime clock.
NOTE: The implementor should be aware of the tradeoff between
accuracy of the database and the internet overhead that the
refresh mechanism introduces. The lifetime period should
be tuned accordingly.
For group names, each end-node must send refresh messages. A node
that fails to do so will be considered to have silently released the
name and dropped from the group.
The lifetime period is established through a simple negotiation
mechanism during name registration: In the name registration
request, the end-node proposes a lifetime value or requests an
infinite lifetime. The NBNS places an actual lifetime value into the
name registration response. The NBNS is always allowed to respond
with an infinite actual period. If the end node proposed an infinite
lifetime, the NBNS may respond with any definite period. If the end
node proposed a definite period, the NBNS may respond with any
definite period greater than or equal to that proposed.
This negotiation of refresh times gives the NBNS means to disable or
enable refresh activity. The end-nodes may set a minimum refresh
cycle period.
NBNS implementations which are completely reliable may disable
refresh.
15.1.3.3. NAME CHALLENGE
To detect whether a node has silently released its claim to a name,
it is necessary on occasion to challenge that node's current
ownership. If the node defends the name then the node is allowed to
continue possession. Otherwise it is assumed that the node has
released the name.
A name challenge may be issued by an NBNS or by a P or M node. A
challenge may be directed towards any end-node type: B, P, or M.
15.1.3.4. GROUP NAME FADE-OUT
NetBIOS groups may contain an arbitrarily large number of members.
The time to challenge all members could be quite large.
To avoid long delays when names are claimed through an NBNS, an
optimistic heuristic has been adopted. It is assumed that there will
always be some node which will defend a group name. Consequently, it
is recommended that the NBNS will immediately reject a claim request
for a unique name when there already exists a group with the same
name. The NBNS will never return an IP address (in response to a
NAME REGISTRATION REQUEST) when a group name exists.
An NBNS will consider a group to have faded out of existence when the
last remaining member fails to send a timely refresh message or
explicitly releases the name.
15.1.3.5. NAME CONFLICT
Name conflict exists when a unique name has been claimed by more than
one node on a NetBIOS network. B, M, and NBNS nodes may detect a
name conflict. The detection mechanism used by B and M nodes is
active only during name discovery. The NBNS may detect conflict at
any time it verifies the consistency of its name database.
B and M nodes detect conflict by examining the responses received in
answer to a broadcast name query request. The first response is
taken as authoritative. Any subsequent, inconsistent responses
represent conflicts.
Subsequent responses are inconsistent with the authoritative response
when:
The subsequent response has the same transaction ID as the
NAME QUERY REQUEST.
AND
The subsequent response is not a duplicate of the
authoritative response.
AND EITHER:
The group/unique characteristic of the authoritative
response is "unique".
OR
The group/unique characteristic of the subsequent
response is "unique".
The period in which B and M nodes examine responses is limited by a
conflict timer, CONFLICT_TIMER. The accuracy or duration of this
timer is not crucial: the NetBIOS system will continue to operate
even with persistent name conflicts.
Conflict conditions are signaled by sending a NAME CONFLICT DEMAND to
the node owning the offending name. Nothing is sent to the node
which originated the authoritative response.
Any end-node that receives NAME CONFLICT DEMAND is required to update
its "local name table" to reflect that the name is in conflict. (The
"local name table" on each node contains names that have been
successfully registered by that node.)
Notice that only those nodes that receive the name conflict message
place a conflict mark next to a name.
Logically, a marked name does not exist on that node. This means
that the node should not defend the name (for name claim purposes),
should not respond to a name discovery requests for that name, nor
should the node send name refresh messages for that name.
Furthermore, it can no longer be used by that node for any session
establishment or sending or receiving datagrams. Existing sessions
are not affected at the time a name is marked as being in conflict.
The only valid user function against a marked name is DELETE NAME.
Any other user NetBIOS function returns immediately with an error
code of "NAME CONFLICT".
15.1.4. ADAPTER STATUS
An end-node or the NBNS may ask any other end-node for a collection
of information about the NetBIOS status of that node. This status
consists of, among other things, a list of the names which the node
believes it owns. The returned status is filtered to contain only
those names which have the same NetBIOS scope identifier as the
requestor's name.
When requesting node status, the requestor identifies the target node
by NetBIOS name A name query transaction may be necessary to acquire
the IP address for the name. Locally cached name information may be
used in lieu of a query transaction. The requesting node sends a
NODE STATUS REQUEST. In response, the receiving node sends a NODE
STATUS RESPONSE containing its local name table and various
statistics.
The amount of status which may be returned is limited by the size of
a UDP packet. However, this is sufficient for the typical NODE
STATUS RESPONSE packet.
15.1.5. END-NODE NBNS INTERACTION
There are certain characteristics of end-node to NBNS interactions
which are in common and are independent of any particular transaction
type.
15.1.5.1. UDP, TCP, AND TRUNCATION
For all transactions between an end-node and an NBNS, either UDP or
TCP may be used as a transport. If the NBNS receives a UDP based
request, it will respond using UDP. If the amount of information
exceeds what fits into a UDP packet, the response will contain a
"truncation flag". In this situation, the end- node may open a TCP
connection to the NBNS, repeat the request, and receive a complete,
untruncated response.
15.1.5.2. NBNS WACK
While a name service request is in progress, the NBNS may issue a
WAIT FOR ACKNOWLEDGEMENT RESPONSE (WACK) to assure the client end-
node that the NBNS is still operational and is working on the
request.
15.1.5.3. NBNS REDIRECTION
The NBNS, because it follows Domain Name system styles of
interaction, is permitted to redirect a client to another NBNS.
15.1.6. SECURED VERSUS NON-SECURED NBNS
An NBNS may be implemented in either of two general ways: The NBNS
may monitor, and participate in, name activity to ensure consistency.
This would be a "secured" style NBNS. Alternatively, an NBNS may be
implemented to be essentially a "bulletin board" on which name
information is posted and responsibility for consistency is delegated
to the end-nodes. This would be a "non-secured" style NBNS.
15.1.7. CONSISTENCY OF THE NBNS DATA BASE
Even in a properly running NetBIOS scope the NBNS and its community
of end-nodes may occasionally lose synchronization with respect to
the true state of name registrations.
This may occur should the NBNS fail and lose all or part of its
database.
More commonly, a P or M node may be turned-off (thus forgetting the
names it has registered) and then be subsequently turned back on.
Finally, errors may occur or an implementation may be incorrect.
Various approaches have been incorporated into the NetBIOS-over- TCP
protocols to minimize the impact of these problems.
1. The NBNS (or any other node) may "challenge" (using a NAME
QUERY REQUEST) an end-node to verify that it actually owns a
name.
Such a challenge may occur at any time. Every end-node must
be prepared to make a timely response.
Failure to respond causes the NBNS to consider that the
end-node has released the name in question.
(If UDP is being used as the underlying transport, the
challenge, like all other requests, must be retransmitted
some number of times in the absence of a response.)
2. The NBNS (or any other node) may request (using the NODE
STATUS REQUEST) that an end-node deliver its entire name
table.
This may occur at any time. Every end-node must be prepared
to make a timely response.
Failure to respond permits (but does not require) the NBNS
to consider that the end-node has failed and released all
names to which it had claims. (Like the challenge, on a UDP
transport, the request must be retransmitted in the absence
of a response.)
3. The NBNS may revoke a P or M node's use of a name by sending
either a NAME CONFLICT DEMAND or a NAME RELEASE REQUEST to
the node.
The receiving end-node may continue existing sessions which
use that name, but must otherwise cease using that name. If
the NBNS placed the name in conflict, the name may be re-
acquired only by deletion and subsequent reclamation. If
the NBNS requested that the name be released, the node may
attempt to re-acquire the name without first performing a
name release transaction.
4. The NBNS may impose a "time-to-live" on each name it
registers. The registering node is made aware of this time
value during the name registration procedure.
Simple or reliable NBNS's may impose an infinite time-to-
live.
5. If an end-node holds any names that have finite time-to-
live values, then that node must periodically send a status
report to the NBNS. Each name is reported using the NAME
REFRESH REQUEST packet.
These status reports restart the timers of both the NBNS and
the reporting node. However, the only timers which are
restarted are those associated with the name found in the
status report. Timers on other names are not affected.
The NBNS may consider that a node has released any name
which has not been refreshed within some multiple of name's
time-to-live.
A well-behaved NBNS, would, however, issue a challenge to-,
or request a list of names from-, the non-reporting end-
node before deleting its name(s). The absence of a
response, or of the name in a response, will confirm the
NBNS decision to delete a name.
6. The absence of reports may cause the NBNS to infer that the
end-node has failed. Similarly, receipt of information
widely divergent from what the NBNS believes about the node,
may cause the NBNS to consider that the end-node has been
restarted.
The NBNS may analyze the situation through challenges or
requests for a list of names.
7. A very cautious NBNS is free to poll nodes (by sending NAME
QUERY REQUEST or NODE STATUS REQUEST packets) to verify that
their name status is the same as that registered in the
NBNS.
NOTE: Such polling activity, if used at all by an
implementation, should be kept at a very low level or
enabled only during periods when the NBNS has some reason to
suspect that its information base is inaccurate.
8. P and M nodes can detect incorrect name information at
session establishment.
If incorrect information is found, NBNS is informed via a
NAME RELEASE REQUEST originated by the end-node which
detects the error.
15.1.8. NAME CACHING
An end-node may keep a local cache of NetBIOS name-to-IP address
translation entries.
All cache entries should be flushed on a periodic basis.
In addition, a node ought to flush any cache information associated
with an IP address if the node receives any information indicating
that there may be any possibility of trouble with the node at that IP
address. For example, if a NAME CONFLICT DEMAND is sent to a node,
all cached information about that node should be cleared within the
sending node.
15.2. NAME REGISTRATION TRANSACTIONS
15.2.1. NAME REGISTRATION BY B NODES
A name claim transaction initiated by a B node is broadcast
throughout the broadcast area. The NAME REGISTRATION REQUEST will be
heard by all B and M nodes in the area. Each node examines the claim
to see whether it it is consistent with the names it owns. If an
inconsistency exists, a NEGATIVE NAME REGISTRATION RESPONSE is
unicast to the requestor. The requesting node obtains ownership of
the name (or membership in the group) if, and only if, no NEGATIVE
NAME REGISTRATION RESPONSEs are received within the name claim
timeout, CONFLICT_TIMER. (See "Defined Constants and Variables" in
the Detailed Specification for the value of this timer.)
A B node proclaims its new ownership by broadcasting a NAME OVERWRITE
DEMAND.
B-NODE REGISTRATION PROCESS
<-----NAME NOT ON NETWORK------> <----NAME ALREADY EXISTS---->
REQ. NODE NODE REQ.NODE
HOLDING
NAME
(BROADCAST) REGISTER (BROADCAST) REGISTER
-------------------> <-------------------
REGISTER REGISTER
-------------------> <-------------------
REGISTER NEGATIVE RESPONSE
-------------------> ------------------------------>
OVERWRITE
-------------------> (NODE DOES NOT HAVE THE NAME)
(NODE HAS THE NAME)
The NAME REGISTRATION REQUEST, like any request, must be repeated if
no response is received within BCAST_REQ_RETRY_TIMEOUT. Transmission
of the request is attempted BCAST_REQ_RETRY_COUNT times.
15.2.2. NAME REGISTRATION BY P NODES
A name registration may proceed in various ways depending whether
the name being registered is new to the NBNS. If the name is known
to the NBNS, then challenges may be sent to the prior holder(s).
15.2.2.1. NEW NAME, OR NEW GROUP MEMBER
The diagram, below, shows the sequence of events when an end-node
registers a name which is new to the NBNS. (The diagram omits WACKs,
NBNS redirections, and retransmission of requests.)
This same interaction will occur if the name being registered is a
group name and the group already exists. The NBNS will add the
registrant to the set of group members.
P-NODE REGISTRATION PROCESS
(server has no previous information about the name)
P-NODE NBNS
REGISTER
--------------------------------->
POSITIVE RESPONSE
<---------------------------------
The interaction is rather simple: the end-node sends a NAME
REGISTRATION REQUEST, the NBNS responds with a POSITIVE NAME
REGISTRATION RESPONSE.
15.2.2.2. EXISTING NAME AND OWNER IS STILL ACTIVE
The following diagram shows interactions when an attempt is made to
register a unique name, the NBNS is aware of an existing owner, and
that existing owner is still active.
There are two sides to the diagram. The left side shows how a non-
secured NBNS would handle the matter. Secured NBNS activity is shown
on the right.
P-NODE REGISTRATION PROCESS
(server HAS a previous owner that IS active)
<------NON-SECURED STYLE-------> <---------SECURED STYLE------->
REQ. NODE NBNS NODE NBNS REQ.NODE
HOLDING
NAME
REGISTER REGISTER
-------------------> <-------------------
QUERY
END-NODE CHALLENGE <------------
<------------------- QUERY
<------------
QUERY
----------------------------->
POSITIVE RESP
QUERY ------------>
-----------------------------> NEGATIVE RESPONSE
----------------->
POSITIVE RESPONSE
<----------------------------
A non-secured NBNS will answer the NAME REGISTRATION REQUEST with a
END-NODE CHALLENGE REGISTRATION RESPONSE. This response asks the
end-node to issue a challenge transaction against the node indicated
in the response. In this case, the prior node will defend against
the challenge and the registering end-node will simply drop the
registration attempt without further interaction with the NBNS.
A secured NBNS will refrain from answering the NAME REGISTRATION
REQUEST until the NBNS has itself challenged the prior holder(s) of
the name. In this case, the NBNS finds that that the name is still
being defended and consequently returns a NEGATIVE NAME REGISTRATION
RESPONSE to the registrant.
Due to the potential time for the secured NBNS to make the
challenge(s), it is likely that a WACK will be sent by the NBNS to
the registrant.
Although not shown in the diagram, a non-secured NBNS will send a
NEGATIVE NAME REGISTRATION RESPONSE to a request to register a unique
name when there already exists a group of the same name. A secured
NBNS may elect to poll (or challenge) the group members to determine
whether any active members remain. This may impose a heavy load on
the network. It is recommended that group names be allowed to fade-
out through the name refresh mechanism.
15.2.2.3. EXISTING NAME AND OWNER IS INACTIVE
The following diagram shows interactions when an attempt is made to
register a unique name, the NBNS is aware of an existing owner, and
that existing owner is no longer active.
A non-secured NBNS will answer the NAME REGISTRATION REQUEST with a
END-NODE CHALLENGE REGISTRATION RESPONSE. This response asks the
end-node to issue a challenge transaction against the node indicated
in the response. In this case, the prior node will not defend
against the challenge. The registrant will inform the NBNS through a
NAME OVERWRITE REQUEST. The NBNS will replace the prior name
information in its database with the information in the overwrite
request.
A secured NBNS will refrain from answering the NAME REGISTRATION
REQUEST until the NBNS has itself challenged the prior holder(s) of
the name. In this case, the NBNS finds that that the name is not
being defended and consequently returns a POSITIVE NAME REGISTRATION
RESPONSE to the registrant.
P-NODE REGISTRATION PROCESS
(server HAS a previous owner that is NOT active)
<------NON-SECURED STYLE-----> <----------SECURED STYLE-------->
REQ. NODE NBNS NODE NBNS REQ.NODE
HOLDING
NAME
REGISTER REGISTER
-------------------> <-------------------
QUERY
END-NODE CHALLENGE <------------
<------------------- QUERY
<------------
NAME QUERY REQUEST POSITIVE RESPONSE
----------------------------> ------------------>
QUERY
---------------------------->
OVERWRITE
------------------->
POSITIVE RESPONSE
<------------------
Due to the potential time for the secured NBNS to make the
challenge(s), it is likely that a WACK will be sent by the NBNS to
the registrant.
A secured NBNS will immediately send a NEGATIVE NAME REGISTRATION
RESPONSE in answer to any NAME OVERWRITE REQUESTS it may receive.
15.2.3. NAME REGISTRATION BY M NODES
An M node begin a name claim operation as if the node were a B node:
it broadcasts a NAME REGISTRATION REQUEST and listens for NEGATIVE
NAME REGISTRATION RESPONSEs. Any NEGATIVE NAME REGISTRATION RESPONSE
prevents the M node from obtaining the name and terminates the claim
operation.
If, however, the M node does not receive any NEGATIVE NAME
REGISTRATION RESPONSE, the M node must continue the claim procedure
as if the M node were a P node.
Only if both name claims were successful does the M node acquire the
name.
The following diagram illustrates M node name registration:
M-NODE REGISTRATION PROCESS
<---NAME NOT IN BROADCAST AREA--> <--NAME IS IN BROADCAST AREA-->
REQ. NODE NODE REQ.NODE
HOLDING
NAME
(BROADCAST) REGISTER (BROADCAST) REGISTER
-------------------> <-------------------
REGISTER REGISTER
-------------------> <-------------------
REGISTER NEGATIVE RESPONSE
-------------------> ------------------------------->
! (NODE DOES NOT HAVE THE NAME)
INITIATE !
A P-NODE !
REGISTRATION !
V
15.3. NAME QUERY TRANSACTIONS
Name query transactions are initiated by end-nodes to obtain the IP
address(es) and other attributes associated with a NetBIOS name.
15.3.1. QUERY BY B NODES
The following diagram shows how B nodes go about discovering who owns
a name.
The left half of the diagram illustrates what happens if there are no
holders of the name. In that case no responses are received in
answer to the broadcast NAME QUERY REQUEST(s).
The right half shows a POSITIVE NAME QUERY RESPONSE unicast by a name
holder in answer to the broadcast request. A name holder will make
this response to every NAME QUERY REQUEST that it hears. And each
holder acts this way. Thus, the node sending the request may receive
many responses, some duplicates, and from many nodes.
B-NODE DISCOVERY PROCESS
<------NAME NOT ON NETWORK------> <---NAME PRESENT ON NETWORK-->
REQ. NODE NODE REQ.NODE
HOLDING
NAME
(BROADCAST) QUERY (BROADCAST) QUERY
----------------------> <---------------------
NAME QUERY REQUEST NAME QUERY REQUEST
----------------------> <---------------------
QUERY POSITIVE RESPONSE
----------------------> ------------------------------>
Name query is generally, but not necessarily, a prelude to NetBIOS
session establishment or NetBIOS datagram transmission. However,
name query may be used for other purposes.
A B node may elect to build a group membership list for subsequent
use (e.g. for session establishment) by collecting and saving the
responses.
15.3.2. QUERY BY P NODES
An NBNS answers queries from a P node with a list of IP address and
other information for each owner of the name. If there are multiple
owners (i.e. if the name is a group name), the NBNS loads as many
answers into the response as will fit into a UDP packet. A
truncation flag indicates whether any additional owner information
remains. All the information may be obtained by repeating the query
over a TCP connection.
The NBNS is not required to impose any order on its answer list.
The following diagram shows what happens if the NBNS has no
information about the name:
P-NODE DISCOVERY PROCESS
(server has no information about the name)
P-NODE NBNS
NAME QUERY REQUEST
--------------------------------->
NEGATIVE RESPONSE
<---------------------------------
The next diagram illustrates interaction between the end-node and the
NBNS when the NBNS does have information about the name. This
diagram shows, in addition, the retransmission of the request by the
end-node in the absence of a timely response. Also shown are WACKs
(or temporary, intermediate responses) sent by the NBNS to the end-
node:
P-NODE QUERY PROCESS
(server HAS information about the name)
P-NODE NBNS
NAME QUERY REQUEST
/---------------------------------------->
/
! (OPTIONAL) WACK
! <- - - - - - - - - - - - - - - - - - - -
! !
!timer !
! ! (optional timer restart)
! !
\ V QUERY
\--------------------------------------->
.
.
.
QUERY
/---------------------------------------->
/
! (OPTIONAL) WACK
! <- - - - - - - - - - - - - - - - - - - -
! !
!timer !
! ! (optional timer restart)
! !
\ V QUERY
\--------------------------------------->
.
.
POSITIVE RESPONSE
<-----------------------------------------
The following diagram illustrates NBNS redirection. Upon receipt of
a NAME QUERY REQUEST, the NBNS redirects the client to another NBNS.
The client repeats the request to the new NBNS and obtains a
response. The diagram shows that response as a POSITIVE NAME QUERY
RESPONSE. However any legal NBNS response may occur in actual
operation.
NBNS REDIRECTION
P-NODE NBNS
NAME QUERY REQUEST
--------------------------------->
REDIRECT NAME QUERY RESPONSE
<---------------------------------
(START FROM THE
VERY BEGINNING
USING THE ADDRESS
OF THE NEWLY
SUPPLIED NBNS.)
NEW
P-NODE NBNS
NAME QUERY REQUEST
--------------------------------->
POSITIVE NAME QUERY RESPONSE
<---------------------------------
The next diagram shows how a P or M node tells the NBNS that the NBNS
has provided incorrect information. This procedure may begin after a
DATAGRAM ERROR packet has been received or a session set-up attempt
has discovered that the NetBIOS name does not exist at the
destination, the IP address of which was obtained from the NBNS
during a prior name query transaction. The NBNS, in this case a
secure NBNS, issues queries to verify whether the information is, in
fact, incorrect. The NBNS closes the transaction by sending either a
POSITIVE or NEGATIVE NAME RELEASE RESPONSE, depending on the results
of the verification.
CORRECTING NBNS INFORMATION BASE
P-NODE NBNS
NAME RELEASE REQUEST
--------------------------------->
QUERY
---------------->
QUERY
---------------->
(NAME TAKEN OFF THE DATABASE
IF NBNS FINDS IT TO BE
INCORRECT)
POSITIVE/NEGATIVE RESPONSE
<---------------------------------
15.3.3. QUERY BY M NODES
M node name query follows the B node pattern. In the absence of
adequate results, the M node then continues by performing a P node
type query. This is shown in the following diagram:
M-NODE DISCOVERY PROCESS
<---NAME NOT ON BROADCAST AREA--> <--NAME IS ON BROADCAST AREA->
REQ. NODE NODE REQ.NODE
HOLDING
NAME
(BROADCAST) QUERY (BROADCAST) QUERY
---------------------> <----------------------
NAME QUERY REQUEST NAME QUERY REQUEST
---------------------> <----------------------
QUERY POSITIVE RESPONSE
---------------------> ------------------------------->
!
INITIATE !
A P-NODE !
DISCOVERY !
PROCESS !
V
15.3.4. ACQUIRE GROUP MEMBERSHIP LIST
The entire membership of a group may be acquired by sending a NAME
QUERY REQUEST to the NBNS. The NBNS will respond with a POSITIVE
NAME QUERY RESPONSE or a NEGATIVE NAME QUERY RESPONSE. A negative
response completes the procedure and indicates that there are no
members in the group.
If the positive response has the truncation bit clear, then the
response contains the entire list of group members. If the
truncation bit is set, then this entire procedure must be repeated,
but using TCP as a foundation rather than UDP.
15.4. NAME RELEASE TRANSACTIONS
15.4.1. RELEASE BY B NODES
A NAME RELEASE DEMAND contains the following information:
- NetBIOS name
- The scope of the NetBIOS name
- Name type: unique or group
- IP address of the releasing node
- Transaction ID
REQUESTING OTHER
B-NODE B-NODES
NAME RELEASE DEMAND
---------------------------------->
15.4.2. RELEASE BY P NODES
A NAME RELEASE REQUEST contains the following information:
- NetBIOS name
- The scope of the NetBIOS name
- Name type: unique or group
- IP address of the releasing node
- Transaction ID
A NAME RELEASE RESPONSE contains the following information:
- NetBIOS name
- The scope of the NetBIOS name
- Name type: unique or group
- IP address of the releasing node
- Transaction ID
- Result:
- Yes: name was released
- No: name was not released, a reason code is provided
REQUESTING
P-NODE NBNS
NAME RELEASE REQUEST
---------------------------------->
NAME RELEASE RESPONSE
<---------------------------------
15.4.3. RELEASE BY M NODES
The name release procedure of the M node is a combination of the P
and B node name release procedures. The M node first performs the P
release procedure. If the P procedure fails then the release
procedure does not continue, it fails. If and only if the P
procedure succeeds then the M node broadcasts the NAME RELEASE DEMAND
to the broadcast area, the B procedure.
NOTE: An M node typically performs a B-style operation and then a
P-style operation. In this case, however, the P-style
operation comes first.
The following diagram illustrates the M node name release procedure:
<-----P procedure fails-------> <-------P procedure succeeds--->
REQUESTING NBNS REQUESTING NBNS
M-NODE M-NODE
NAME RELEASE REQUEST NAME RELEASE REQUEST
--------------------------> ------------------------>
NEGATIVE RELEASE RESPONSE POSITIVE RELEASE RESPONSE
<-------------------------- <-------------------------
OTHER
M-NODES
NAME RELEASE DEMAND
------------------------>
15.5. NAME MAINTENANCE TRANSACTIONS
15.5.1. NAME REFRESH
Name refresh transactions are used to handle the following
situations:
a) An NBNS node needs to detect if a P or M node has "silently"
gone down, so that names held by that node can be purged
from the data base.
b) If the NBNS goes down, it needs to be able to reconstruct
the data base when it comes back up.
c) If the network should be partitioned, the NBNS needs to be
able to able to update its data base when the network
reconnects.
Each P or M node is responsible for sending periodic NAME REFRESH
REQUESTs for each name that it has registered. Each refresh packet
contains a single name that has been successfully registered by that
node. The interval between such packets is negotiated between the
end node and the NBNS server at the time that the name is initially
claimed. At name claim time, an end node will suggest a refresh
timeout value. The NBNS node can modify this value in the reply
packet. A NBNS node can also choose to tell the end node to not send
any refresh packet by using the "infinite" timeout value in the
response packet. The timeout value returned by the NBNS is the
actual refresh timeout that the end node must use.
When a node sends a NAME REFRESH REQUEST, it must be prepared to
receive a negative response. This would happen, for example, if the
the NBNS discovers that the the name had already been assigned to
some other node. If such a response is received, the end node should
mark the name as being in conflict. Such an entry should be treated
in the same way as if name conflict had been detected against the
name. The following diagram illustrates name refresh:
<-----Successful Refresh-----> <-----Unsuccessful Refresh---->
REFRESHING NBNS REFRESHING NBNS
NODE NODE
NAME REFRESH REQUEST NAME REFRESH REQUEST
------------------------> ----------------------->
POSITIVE RESPONSE NEGATIVE RESPONSE
<------------------------ <-----------------------
!
!
V
MARK NAME IN
CONFLICT
15.5.2. NAME CHALLENGE
Name challenge is done by sending a NAME QUERY REQUEST to an end node
of any type. If a POSITIVE NAME QUERY RESPONSE is returned, then
that node still owns the name. If a NEGATIVE NAME QUERY RESPONSE is
received or if no response is received, it can be assumed that the
end node no longer owns the name.
Name challenge can be performed either by the NBNS node, or by an end
node. When an end-node sends a name claim packet, the NBNS node may
do the challenge operation. The NBNS node can choose, however, to
require the end node do the challenge. In that case, the NBNS will
send an END-NODE CHALLENGE RESPONSE packet to the end node, which
should then proceed to challenge the putative owner.
Note that the name challenge procedure sends a normal NAME QUERY
REQUEST packet to the end node. It does not require a special
packet. The only new packet introduced is the END-NODE CHALLENGE
RESPONSE which is sent by an NBNS node when the NBNS wants the end-
node to perform the challenge operation.
15.5.3. CLEAR NAME CONFLICT
It is possible during a refresh request from a M or P node for a NBNS
to detects a name in conflict. The response to the NAME REFRESH
REQUEST must be a NEGATIVE NAME REGISTRATION RESPONSE. Optionally,
in addition, the NBNS may send a NAME CONFLICT DEMAND or a NAME
RELEASE REQUEST to the refreshing node. The NAME CONFLICT DEMAND
forces the node to place the name in the conflict state. The node
will eventually inform it's user of the conflict. The NAME RELEASE
REQUEST will force the node to flush the name from its local name
table completely. This forces the node to flush the name in
conflict. This does not cause termination of existing sessions using
this name.
The following diagram shows an NBNS detecting and correcting a
conflict:
REFRESHING NODE NBNS
NAME REFRESH REQUEST
----------------------------------------->
NEGATIVE NAME REGISTRATION RESPONSE
<-----------------------------------------
NAME CONFLICT DEMAND
<-----------------------------------------
OR
NAME RELEASE REQUEST
<-----------------------------------------
POSITIVE/NEGATIVE RELEASE REQUEST
----------------------------------------->
15.6. ADAPTER STATUS TRANSACTIONS
Adapter status is obtained from a node as follows:
1. Perform a name discovery operation to obtain the IP
addresses of a set of end-nodes.
2. Repeat until all end-nodes from the set have been used:
a. Select one end-node from the set.
b. Send a NODE STATUS REQUEST to that end-node using UDP.
c. Await a NODE STATUS RESPONSE. (If a timely response is
not forthcoming, repeat step "b" UCAST_REQ_RETRY_COUNT
times. After the last retry, go to step "a".)
d. If the truncation bit is not set in the response, the
response contains the entire node status. Return the
status to the user and terminate this procedure.
e. If the truncation bit is set in the response, then not
all status was returned because it would not fit into
the response packet. The responder will set the
truncation bit if the IP datagram length would exceed
MAX_DATAGRAM_LENGTH. Return the status to the user and
terminate this procedure.
3. Return error to user, no status obtained.
The repetition of step 2, above, through all nodes of the set, is
optional.
Following is an example transaction of a successful Adapter Status
operation:
REQUESTING NODE NAME OWNER
NAME QUERY REQUEST
----------------------------------------->
POSITIVE NAME QUERY RESPONSE
<-----------------------------------------
NODE STATUS REQUEST
----------------------------------------->
NODE STATUS RESPONSE
<-----------------------------------------
16. NetBIOS SESSION SERVICE
The NetBIOS session service begins after one or more IP addresses
have been found for the target name. These addresses may have been
acquired using the NetBIOS name query transactions or by other means,
such as a local name table or cache.
NetBIOS session service transactions, packets, and protocols are
identical for all end-node types. They involve only directed
(point-to-point) communications.
16.1. OVERVIEW OF NetBIOS SESSION SERVICE
Session service has three phases:
Session establishment - it is during this phase that the IP
address and TCP port of the called name is determined, and a
TCP connection is established with the remote party.
Steady state - it is during this phase that NetBIOS data
messages are exchanged over the session. Keep-alive packets
may also be exchanged if the participating nodes are so
configured.
Session close - a session is closed whenever either a party (in
the session) closes the session or it is determined that one
of the parties has gone down.
16.1.1. SESSION ESTABLISHMENT PHASE OVERVIEW
An end-node begins establishment of a session to another node by
somehow acquiring (perhaps using the name query transactions or a
local cache) the IP address of the node or nodes purported to own the
destination name.
Every end-node awaits incoming NetBIOS session requests by listening
for TCP calls to a well-known service port, SSN_SRVC_TCP_PORT. Each
incoming TCP connection represents the start of a separate NetBIOS
session initiation attempt. The NetBIOS session server, not the
ultimate application, accepts the incoming TCP connection(s).
Once the TCP connection is open, the calling node sends session
service request packet. This packet contains the following
information:
- Calling IP address (see note)
- Calling NetBIOS name
- Called IP address (see note)
- Called NetBIOS name
NOTE: The IP addresses are obtained from the TCP service
interface.
When the session service request packet arrives at the NetBIOS
server, one of the the following situations will exist:
- There exists a NetBIOS LISTEN compatible with the incoming
call and there are adequate resources to permit session
establishment to proceed.
- There exists a NetBIOS LISTEN compatible with the incoming
call, but there are inadequate resources to permit
establishment of a session.
- The called name does, in fact, exist on the called node, but
there is no pending NetBIOS LISTEN compatible with the
incoming call.
- The called name does not exist on the called node.
In all but the first case, a rejection response is sent back over the
TCP connection to the caller. The TCP connection is then closed and
the session phase terminates. Any retry is the responsibility of the
caller. For retries in the case of a group name, the caller may use
the next member of the group rather than immediately retrying the
instant address. In the case of a unique name, the caller may
attempt an immediate retry using the same target IP address unless
the called name did not exist on the called node. In that one case,
the NetBIOS name should be re-resolved.
If a compatible LISTEN exists, and there are adequate resources, then
the session server may transform the existing TCP connection into the
NetBIOS data session. Alternatively, the session server may
redirect, or "retarget" the caller to another TCP port (and IP
address).
If the caller is redirected, the caller begins the session
establishment anew, but using the new IP address and TCP port given
in the retarget response. Again a TCP connection is created, and
again the calling and called node exchange credentials. The called
party may accept the call, reject the call, or make a further
redirection.
This mechanism is based on the presumption that, on hosts where it is
not possible to transfer open TCP connections between processes, the
host will have a central session server. Applications willing to
receive NetBIOS calls will obtain an ephemeral TCP port number, post
a TCP unspecified passive open on that port, and then pass that port
number and NetBIOS name information to the NetBIOS session server
using a NetBIOS LISTEN operation. When the call is placed, the
session server will "retarget" the caller to the application's TCP
socket. The caller will then place a new call, directly to the
application. The application has the responsibility to mimic the
session server at least to the extent of receiving the calling
credentials and then accepting or rejecting the call.
16.1.1.1. RETRYING AFTER BEING RETARGETTED
A calling node may find that it can not establish a session with a
node to which it was directed by the retargetting procedure. Since
retargetting may be nested, there is an issue whether the caller
should begin a retry at the initial starting point or back-up to an
intermediate retargetting point. The caller may use any method. A
discussion of two such methods is in Appendix B, "Retarget
Algorithms".
16.1.1.2. SESSION ESTABLISHMENT TO A GROUP NAME
Session establishment with a group name requires special
consideration. When a NetBIOS CALL attempt is made to a group name,
name discovery will result in a list (possibly incomplete) of the
members of that group. The calling node selects one member from the
list and attempts to build a session. If that fails, the calling
node may select another member and make another attempt.
When the session service attempts to make a connection with one of
the members of the group, there is no guarantee that that member has
a LISTEN pending against that group name, that the called node even
owns, or even that the called node is operating.
16.1.2. STEADY STATE PHASE OVERVIEW
NetBIOS data messages are exchanged in the steady state. NetBIOS
messages are sent by prepending the user data with a message header
and sending the header and the user data over the TCP connection.
The receiver removes the header and passes the data to the NetBIOS
user.
In order to detect failure of one of the nodes or of the intervening
network, "session keep alive" packets may be periodically sent in the
steady state.
Any failure of the underlying TCP connection, whether a reset, a
timeout, or other failure, implies failure of the NetBIOS session.
16.1.3. SESSION TERMINATION PHASE OVERVIEW
A NetBIOS session is terminated normally when the user requests the
session to be closed or when the session service detects the remote
partner of the session has gracefully terminated the TCP connection.
A NetBIOS session is abnormally terminated when the session service
detects a loss of the connection. Connection loss can be detected
with the keep-alive function of the session service or TCP, or on the
failure of a SESSION MESSAGE send operation.
When a user requests to close a session, the service first attempts a
graceful in-band close of the TCP connection. If the connection does
not close within the SSN_CLOSE_TIMEOUT the TCP connection is aborted.
No matter how the TCP connection is terminated, the NetBIOS session
service always closes the NetBIOS session.
When the session service receives an indication from TCP that a
connection close request has been received, the TCP connection and
the NetBIOS session are immediately closed and the user is informed
of the loss of the session. All data received up to the close
indication should be delivered, if possible, to the session's user.
16.2. SESSION ESTABLISHMENT PHASE
All the following diagrams assume a name query operation was
successfully completed by the caller node for the listener's name.
This first diagram shows the sequence of network events used to
successfully establish a session without retargetting by the
listener. The TCP connection is first established with the well-
known NetBIOS session service TCP port, SSN_SRVC_TCP_PORT. The
caller then sends a SESSION REQUEST packet over the TCP connection
requesting a session with the listener. The SESSION REQUEST contains
the caller's name and the listener's name. The listener responds
with a POSITIVE SESSION RESPONSE informing the caller this TCP
connection is accepted as the connection for the data transfer phase
of the session.
CALLER LISTENER
TCP CONNECT
====================================>
TCP ACCEPT
<===================================
SESSION REQUEST
------------------------------------>
POSITIVE RESPONSE
<-----------------------------------
The second diagram shows the sequence of network events used to
successfully establish a session when the listener does retargetting.
The session establishment procedure is the same as with the first
diagram up to the listener's response to the SESSION REQUEST. The
listener, divided into two sections, the listen processor and the
actual listener, sends a SESSION RETARGET RESPONSE to the caller.
This response states the call is acceptable, but the data transfer
TCP connection must be at the new IP address and TCP port. The
caller then re-iterates the session establishment process anew with
the new IP address and TCP port after the initial TCP connection is
closed. The new listener then accepts this connection for the data
transfer phase with a POSITIVE SESSION RESPONSE.
CALLER LISTEN PROCESSOR LISTENER
TCP CONNECT
=============================>
TCP ACCEPT
<=============================
SESSION REQUEST
----------------------------->
SESSION RETARGET RESPONSE
<-----------------------------
TCP CLOSE
<=============================
TCP CLOSE
=============================>
TCP CONNECT
====================================================>
TCP ACCEPT
<====================================================
SESSION REQUEST
---------------------------------------------------->
POSITIVE RESPONSE
<----------------------------------------------------
The third diagram is the sequence of network events for a rejected
session request with the listener. This type of rejection could
occur with either a non-retargetting listener or a retargetting
listener. After the TCP connection is established at
SSN_SRVC_TCP_PORT, the caller sends the SESSION REQUEST over the TCP
connection. The listener does not have either a listen pending for
the listener's name or the pending NetBIOS listen is specific to
another caller's name. Consequently, the listener sends a NEGATIVE
SESSION RESPONSE and closes the TCP connection.
CALLER LISTENER
TCP CONNECT
====================================>
TCP ACCEPT
<===================================
SESSION REQUEST
------------------------------------>
NEGATIVE RESPONSE
<-----------------------------------
TCP CLOSE
<===================================
TCP CLOSE
====================================>
The fourth diagram is the sequence of network events when session
establishment fails with a retargetting listener. After being
redirected, and after the initial TCP connection is closed the caller
tries to establish a TCP connection with the new IP address and TCP
port. The connection fails because either the port is unavailable or
the target node is not active. The port unavailable race condition
occurs if another caller has already acquired the TCP connection with
the listener. For additional implementation suggestions, see
Appendix B, "Retarget Algorithms".
CALLER LISTEN PROCESSOR LISTENER
TCP CONNECT
=============================>
TCP ACCEPT
<=============================
SESSION REQUEST
----------------------------->
REDIRECT RESPONSE
<-----------------------------
TCP CLOSE
<=============================
TCP CLOSE
=============================>
TCP CONNECT
====================================================>
CONNECTION REFUSED OR TIMED OUT
<===================================================
16.3. SESSION DATA TRANSFER PHASE
16.3.1. DATA ENCAPSULATION
NetBIOS messages are exchanged in the steady state. Messages are
sent by prepending user data with message header and sending the
header and the user data over the TCP connection. The receiver
removes the header and delivers the NetBIOS data to the user.
16.3.2. SESSION KEEP-ALIVES
In order to detect node failure or network partitioning, "session
keep alive" packets are periodically sent in the steady state. A
session keep alive packet is discarded by a peer node.