Ref: 03990001
Title: Typical XNS Sockets Used By 3+
Date: 11/07/89

Copyright 3Com Corporation, 1991.  All rights reserved.

462 : PEP 3Mail

Typically, this is used by Mail Minder to check if a user has mail.
Depending on which version of mail is being used on the workstation,
pressing F8 may cause this type of packet to be generated before a
virtual SPP connection is actually established to the mail server.  This
packet contains the name of the user whose inbox should be checked
(request) and a return packet that has a 'true' or 'false' indication in
it as to whether there is any mail to get.

463 : SPP 3Mail

This is a virtual circuit connection socket to get the mail server's
attention.  The mail server is listening for connection requests on
socket 463 then will move off to a pair of 'not well-known sockets' for
subsequent communications with the workstation.  The workstation
initiates the connection.  Either side may break the connection.  At any
given time you may have up to MSPROC simultaneous connections of this
type to a mail server (if you are a local user).

464 : PEP 3Name

This is used for most Name service requests.  Any request that can be
satisfied with a one-packet response will typically use this type of
packet.  Login, for example, uses this type of packet to request and
receive all relevant information about the user logging in.  This
information is then placed in the LGL.SYS driver so you do not need to
continuously ask for the same data again and again.  In any PEP type of
packet, the server always receives the packet on the 'well-known socket'
and does not move to a temporary socket as is the case in SPP.

465 : SPP 3Name

This is used for Name service requests that return lists of
information.  For example, '3n dir *:cso:3com' will return a list of
users.  When you execute this command on your workstation, a packet is
sent out directed to socket 465.  It is an SPP packet asking to establish
a session with the server.  The server responds on a 'not well-known
socket' and the workstation acknowledges.  The data is then downloaded
over this session.  When all the data has been downloaded to the
workstation, the session is broken.  The Name server supports one of
these sessions at a time.  If two users were to type '3n dir' at exactly
the same time, only one would get the session.  The other user would
continue to retry the operation until it either timed out or until the
first user released the session allowing the second user to make the
session.

466 : PEP 3Time

This is used to obtain the time of day from the server.  A process that is
actually part of 3NAMEE.EXE is responsible for listening for these '3time'
requests.  LOGIN.EXE asks for the time from the server as part of logging in.
In fact, it is the last two packets that are sent and received by LOGIN.EXE.
The format of the returned data is the date and time in GMT and a number of
minutes offset from the prime meridian.

468 : SPP 3File/3Print

This is the socket that the 3share 'listener' listens on for new 3f/
3p connections.  A session is established with a 3share server when you
do your FIRST link with that server.  Printer links count too.  As is the
case in all SPP connections, the server must listen on a well-known
socket for a connection request.  When it hears one, it moves off onto a
unique socket which will be used for the remainder of the session.  Your
session is kept intact until you do your last 'unlink' from the server,
logout, login again, or reboot your workstation.  It is also possible for
another user to break your session if they have admin capabilities.  SPP
is used in cases where potentially large amounts of data will be
transfered between client and server because it does not require an ACK
packet after every packet of useful data.  In fact, using 3+Share 1.3.1,
it is possible to expand the window so that ACK packets are required
after every 12 data packets.  This results in great performance but eats
up a lot of memory on both the server and workstation.

46d : Locator (also 46b & 46c)

Sockets 46c and 46d are standard Locator sockets, used for
heartbeat and other types of Locator traffic.  They are PEP protocol
packets.  When a workstation does a heartbeat or some NetBIOS function
that requires data from the locator, it sends a PEP packet from source
socket 046c to destination socket 046d, where the Locator is listening for
traffic.  The local NetBIOS on your workstation is listening on socket 46c
for replies.

If a station has a NetBIOS 'listen' pending, it's also listening on
socket 46b.  When a NetBIOS station wants to establish a session with
another node on the network, one side must do a call and the other must do
a listen.  The calling station will send a packet to the listening station
on socket 46b.  When the listening station hears this request, it will move
onto a 'not well-known socket' for further traffic associated with this
session.  This is exactly the same idea as all the other SPP cases cited
above.  Either side may break the session by doing a NetBIOS 'hang-up'.

401 : EtherDisk (EtherStart / 3+Start / 3+Open Start)

This socket is exclusively PEP.  It was originally used by Etherseries
and EtherStart; now it is also used by 3+Start and 3+Open Start.  It is a
very simple protocol.  Different commands are supported by this
interface.  A client may build a command block and send to a server (such
as a start server) using socket 401.  3+Start, for example, is listening
for packets of this type.  The server will receive the data, decode the
command, and send the reply.  Because it is PEP protocol, there can only
be one packet outstanding in any direction - hence it is less efficient
than SPP.

OTHER sockets:

Most of these are obsolete since they typically had to do with
Etherseries.  They were generally all PEP protocol packets.

402 - ethermail (PEP)
403 - etherprint (PEP)
404 - etherbackup (PEP)
405 - etheradmin (PEP)
410 - etheruser station (PEP)
411 - etherconsole (PEP)
412 - etherfloppy (PEP)
455 - ether3270

