Text 222, 138 rader
Skriven 2006-07-08 09:33:02 av Peter Knapper (3:772/1.10)
    Kommentar till text 218 av Mike Powell (1:2320/105.0)
Ärende: Starting the Requestor
==============================
Hi Mike,

 MP> On my old system, there is the NETSTCMD.CMD, which starts with 
 MP> the parameters START PEER.  There is also the TCPSTART.CMD.

NETSTCMD.CMD is a simple .CMD file that is usually run from an object in the
startup Folder and that .CMD file simpy issues a "NET START PEER" command.

It is VERY important that you understand that the startup of TCP/IP has
absolutely NOTHING to do with PEER, they are completely separate components of
Networking for OS/2. They CAN be related if the user sets things up like that
but they do not HAVE to be related.

For Warp 4, TCPSTART.CMD is usually run from the STARTUP Folder.

Peer can actually be started in 2 main ways -
  1. By explicitly starting the Peer components you want started (EG NET START
xxx). 

  2. By running a LOGON for Peer. The LOGON effectively issues a NET START PEER
before the LOGON is processed. This is how I start peer here, my STARTUP.CMD
file logs in a default user that starts Peer.

With Peer already runing on a machine enter "NET START" (with no 3rd parameter)
on the commandline and it will display the PEER components that are currently
running. 

In addtion, it is important to know that Peer has several sub components -
  Server        Allows THIS machine to offer up Network resources,
  Requester     Allows this machine to CONNECT to other SERVERS.
  Messenger     Allows users on 2 Peer machines to "talk to each other (ammong
other things), plus others that are rarely used. 

So starting PEER defaults to starting all of the above. You can also stop (and
start) each component individually (EG: NET STOP MESSENGER), however stopping
one Peer service, may also stop another Peer service, or eveything, as there
are some not so obvious relationships in there.......;-)


 MP> This may actually be redundant.  When I put these in for the newer,
 MP> faster system, the NETSTCMD returns an error (Requester is already 
 MP> being started). That is because TCPSTART runs so fast, it calls 
 MP> TCPEXIT, which has the LOGON command in the first line.  

As you say, TCPSTART runs in 1-2 seconds, its pretty much instant.
TCPEXIT can be useful for VMODEM startup, as that requires TCP/IP to be
available first.

As above, a LOGON forces a NET START PEER. Yes it can be placed in the TCPSTART
file, but this method would mean there is a relationship between the startup of
TCP/IP and Peer, but its not REQUIRED, as Peer is not dependant on TCP/IP. If
you wished, you could NOT run TCPSTART.CMD at all but still start up Peer!

I much prefer to control all of these myself, so I remove them from the Startup
Folder and call them individually in STARTUP.CMD in the exact sequence I want.

 MP> So it is already attempting to start the
 MP> requester so that the logon can continue.

Explicity attempting to LOGIN a user to Peer (IE running the peer LOGIN.EXE),
can also be used to automatically start up the Requester if its not runing. You
can't start the Requestor unless you have PEER running, which is why you end up
starting multiple Peer Services.......;-). That is just another way to start
Peer Services (OS/2 Peer or File and Printer Sharing, these are all the same
product). 


 MP> On the old system, the NETSTCMD does the NET START PEER 
 MP> before TCPEXIT runs, so
 MP> TCPEXIT waits until the requester is started before completing the LOGON
 MP> command, which is why I never got the error!

There is no DIRECT relationship between PEER and TCP/IP, they are totally
different products with no dependency of one for the other! HOWEVER, BOTH of
them require your NETWORK Card driver to be runing, along with the Transport
drivers for the protocols you need, otherwise they have no PROTOCOL Stack to
talk to...

The sequence of dependencies for an OS/2 environemnt is this -
        The NIC Driver, IE your Network Card is the BOTTOM component.
          If you wish to run TCP/IP, then you run the TCP/IP stack.
          If you wish to run PEER, then you run the NETBEUI stack.
          If you want you Peer to be able to communicate outside your 
                own LAN, then you need the NETBEUI stack loaded first          
               AND then you need the TCPBEUI stack. TCPBEUI requires 
                NETBEUI to operate.
            Now you can run TCP/IP applications,
            Now you can run PEER applications.
        
One thing to remember, is that if you do NOT have a LAN, but still use Dial-up
internet access, then your machine loads a DUMMY NIC Driver so that when you
run PPP (via whatever dialer you use), PPP has something to "BIND" to.

A little bit more detail -
When People talk about "TCP/IP" there are actually 2 main components, the
TCP/IP "Protocol Stack" or Communications Transport Layer for TCP/IP, and the
TCP/IP utility program, the tools provided (such as FTP, Sendmail, TFTP, etc)
so the user can access the TCP/IP Transport Layer.

Peer also has a Communcatiosn Transport Layer like TCP/IP However that layer is
called NETBIOS. Without a NETBIOS environment runing on a machine, Peer wont
start. Similar to the way the TCP/IP tools MUST have the TCP/IP Transport
Layer, Peer tools MUST use the NETBIOS (also can be known as NETBEUI) Transport
Layer.

The ONLY link between Peer and TCP/IP comes when you wish to talk PEER with a
machine that is NOT connected to the SAME LAN Segment as your first machine.
NETBIOS (NETBEUI) itself is NOT a Routable protocol like TCP/IP (which is
Routable), so to allow it to travel OFF your LAN to other places on the
network, you need to ENCAPSULATE your NETBIOS data in a TCP/IP frame, and this
happens in what is known as TCPBEUI or "NETBIOS over TCP/IP".

Your PEER Network ONLY natively talks the NETBIOS (or more specifically
NETBEUI) protocol.

So to the non-obvious, if you configure NETBIOS over TCP/IP within MPTS on your
machine, then you are sort of ADDING capability to Peer, but this is NOT a
requirement for Peer to operate (unless you need to talk to Win98 or later
machines, because Bill Gates has basterdized the protocol relationships at his
end and TCPBEUI is ALWAYS required on a non-Windows machine for them to work).


 MP> Funny thing now... my router does not appear to see the 
 MP> new box, but it can PING the router, and the other boxes, 
 MP> and also can reach the internet.  Not bad at all!  ;-)

By this do you mean you can PING A from B, but not PING B from A? If so then
you have a configuration issue on one of the boxes (most likely a NETMASK or
Default Gateway setting is missing or wrong), or there is an Access List (a
control file defining who can talk to whom) preventing this visibility...

Welcome to the world of Networking........;-)

Cheers............pk.


--- Maximus/2 3.01
 * Origin: Another Good Point About OS/2 (3:772/1.10)