ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng)/ProfitPress-MegaCDROM2.B6I/DESQVIEW/TECH/DVXTEC.ZIP/PCTCP.TEC

Text File | 1992-03-31 | 17.7 KB | 384 lines

                Remote Computing with DESQview/X.


 Remote computing is a field that DESQview/X is very much involved in.
Unfortunatly there is an abundance of variables that can greatly complicate
the running of applications remotely under DESQview/X. This technical
report covers the implementation of a remote computing environment with
FTP's TCP/IP version 2.03 and DESQview/X.


Some general notes about TCP/IP Networks.

 Most of the Unix networks in the world today conform to a protocol
called the Internet Protocol Suite. Of all the network protocols, the
Transmission Control Protocol (TCP) and the Internet Protocol (IP) are
the most widely used. The Internet Protocol Suite was used as a
foundation for the Open Systems Interconnection (OSI) Reference Model,
which is accepted as a international standard. The OSI Reference Model
is based on a seven layer model of communications.

Application Layer   - This layer describes how application services like
                      file transfering, electronic mail and terminal
                      emulation will run on different computers.

Presentation Layer  - This layer manages the format of data, and ensures
                      that different machines can understand each other.

Session Layer       - The Session layer ensures that reliable
                      communication sessions between computers are
                      established. It works with the Transport layer to
                      descibe the way sessions can be set up.

Transport layer     - The Transport Layer specifies the setting up of
                      reliable communications between computers (TCP).

Network Layer       - Provides routing information for establishing
                      communications between two machines over a network
                      (IP).

Data Link Layer     - Network protocols for synchronizing communication
                      and error handling over the physical layer. ie,
                      Ethernet, StarLAN, Token Ring and Serial
                      Communications.

Physical Layer      - Network hardware.

 A TCP/IP network works by converting blocks of data into packets. At
the beginning of each packet is a header that contains the control
information which is the address of the destination, followed by the
data. When a large file is sent across a TCP/IP network its contents
are broken down into a series of packets.

 The Internet Protocol (IP) which corresponds to the OSI Network Layer
allows applications to run transparently across networks. When IP is
used, applications do not need to know about the network hardware. The
same application can run across Local Area Networks (corresponding to
the OSI Physical and Data Link layers) such as Ethernet, StarLAN, or
Token Ring, or a Wide Area Network like X.25.

 The Transmission Control Protocol (TCP) corresponds with the OSI
Transport layer, it ensures that data is delivered to the correct
address, it checks that the data recieved was the same that was sent and
the packets are received in the correct order.

 Unix System V Release 4 for the first time incorporated an Internet
TCP/IP package. Previously TCP/IP was available only as an add-in.
Release 4 includes two sets of commands, the DARPA Commands and the
Berkeley Remote Commands. The latter was developed at UC Berkeley.
The DARPA Command set include facilities independant of the operating
system, these include terminal emulation, file transfer, mail and
obtaining information on users. These commands can be used for networking
with computers running operating systems other than Unix (i.e. DOS). The
Berkeley Remote Commands include Unix to Unix System commands for remote
copying of files, remote login, remote shell execution and facilities
for obtaining information on remote systems and users.

 On a TCP/IP network every node (known as a host) has an Internet
address. For peer to peer communication, both hosts must be "aware" of
the other, this is achieved by having an entry, that includes a IP
address and usually a name, for each remote host in the host tables on
each machine (see the example host file below). An IP address is a 32
bit number, expressed as 4 decimal octects in dot notation. For example
128.40.10.230 (please note that the IP address is not the same as the
card address). Internet addressing schemes:

                  Range         Network Part    Host Part
Class A           0-127         xxx             xxx.xxx.xxx
Class B         128-191         xxx.xxx         xxx.xxx
Class C         192-223         xxx.xxx.xxx     xxx

 So by following the above example, 125.10.3.25 is Host 10.3.25 on
Network 125. Hosts can also be addressed by a name in two ways:
1. Local host file turns name into an Internet address.
2. Nameserver turns a server name into an address.

 Any machine with more than one network interface could be made to act
as a router/gateway. The subnet mask is used by routers to increase the
speed of the routing algorithm. Normally the default is to your network
path.

 So if a Class B Network is xxx.xxx the subnet would be 255.255.0.0. If
the nodes 0-127.xxx are on Ethernet and nodes 128-255.xxx are on Token
Ring the subnet would be 255.255.128.0. Nodes 0 and all ones are
reserved.

A typical Host file :

address         name            nickname/alias
128.17.5.4      accounts        alr386 mole
128.17.4.17     support         dec333 serval
128.17.4.18     support         sparc2+ mink
128.17.3.17     marketing       sgi4d hamster



Configuring the DOS TCP/IP.

Configuring DESQview/X.

 To configure DESQview/X to handle TCP/IP packets, the DVX.CFG must be
modified by adding the following line to the file "net pctcp". Below is
an example of a DVX.CFG file with the modification added:

net pctcp
client dwm,appman
type VGA
arch 2
dispsize 224x168
screen 800x600:58h
#screen 640x480:12h
fp fonts\misc,fonts\75dpi
bc
bs on

Installation of the software.

 Currently the only TCP/IP drivers for DOS that work with DESQview/X are
FTP's PC/TCP version 2.03. Before running the initial "a:install" the
user should determine which card they are going to use and determine
hardware conflicts with existing devices. Ensure that you have the
correct driver for your card by reading your installation manual and
looking at the driver/card table in the installation chapter. The
install procedure will ask you where to install the software. C:\FTP is
the standard directory. It then copies all of the relevant files to that
directory. It is left to the user to modify his Config.Sys and his
Autoexec.Bat. This also documented in the FTP PC/TCP manual.

 The user can use the "ifconfig" utility to ensure that both the drivers
(ipcust.sys and the relevant device driver for his network card, refered
to as "interface.sys" in the FTP manuals)  are configured correctly. In
the IPCUST.SYS file the only critical entry is the location of the host
table. This is the line that reads:

Host table (hosttable): c:\ftp\hosts.hst

 This entry must point to the correct file in the correct directory.
Another potential problem area is running out of sockets or packets
while running DESQview/X. The default amount of sockets is four and two
packets. Each remote application requires one packet. If you are running
an application inside of an Xterm that will require two packets one for
the application and one for Xterm. The syntax for increasing sockets and
packets is as follows ("t" is for sockets and "p" is for packets, and
"INTERFACE.SYS" is the relevant driver for your network card):

DEVICE=C:\FTP\INTERFACE.SYS -t 16 -p 8


Testing PC/TCP.

 To test PC/TCP the PING utility should be tried initially. Firstly
trying to ping the local host should be the first test, and will show if
the network is configured correctly locally; this would be done by
typing:

ping localhost

If the test has passed the response should be:

Host responding

 This message will be followed by some confirmation statistics. What
this means is that the Ping.Exe has executed and that the Kernel is
loaded correctly. When you Ping Localhost with FTP, it only checks to
see if the Kernel is loaded. If the test fails, the PING program will
generate a message, some of the more common messages are:

Host not responding

Host unreachable -

This usually means that the Kernel hasn't even tried to assign a
packet to be sent because it doesn't recognize the IP address as a valid
IP address to transmit to. This can usually be fixed by ensuring that
the first two octects in the IP address corespond to the physical
networks configuration.

Host unreachable: ARP failed -

Addressed Resolution Protocol, usually fails when the specific host
cannot be found on the network, or the last octects in hte IP address
are incorrect.

 The error message is followed by some more statistics. If the PING
fails locally it means that your software is not configured or that your
network card is not working correctly. If your card has some form of
diagnostic utility, you should probably review it. For more help you
should consult the FTP manual, under the "Problem Soloving" chapter.
Conversely, if the local PING works you can try to PING a remote
xmachine. This uses similar syntax to the previous command:

ping <HOST>

 In this case <HOST> is the remote machine. If this fails then you have
double the potential causes to detect. You should at this stage try to
PING from the remote host. If this fails then the network hardware
should fall under scrutiny. The following steps might help, but as
always the user should refer to the FTP manual as mentioned above.

1 - If you can PING one way but not both, then setup and configuration
    on the node that refuses to respond to PING could be to blame.

2 - If you can PING localhost but not remote then bad hardware ie,
    network card or cable, could possibly be the cause.

 Once the PING utilty is working properly, the other TCP/IP utilities
can be used to test the network. The File Transfer Protocol, a utility
for transfering files is a good test for evalaluating the ability of the
network. FTP is invoked by running FTP.EXE from the DOS command prompt,
this will allow you to transfer files between hosts by using the
functions "put" and "get" to copy to and copy from remote machines. If
the FTP utility fails but remote PING works,then refer to the paragraph
above mentioning increasing system resources, specifically packets.
Failure at this point should lead to the trouble shooting section of the
FTP manual, as mentioned elsewhere. The Remote Login utility RLOGIN is
another test that could be tried to determine how well the network is
functioning. It allows the user to log in to a remote host. The syntax
would be as follows (as before <HOST> refers to the remote machine);

rlogin <HOST>

If this fails then the respective host files should be checked, as
should the system resources.


DOS to DOS Networking.

 To run an application on one machine and display it on another, the
Remote Shell (RSH) command should be used. This should be run from the
DOS command line as follows;

rsh <HOST> <user> <application (path if needed)> -display <display>:0

<HOST>        Corresponds to the machine (remote or local) that the
              following application shall be processed on. This can be
              represented by either the IP address or the HOST name,
              presuming the host names match with the relevant host
              tables.

<user>        If the <HOST> machine has some form of security or user
              restrictions then a user account will have to be opened,
              DOS machines do not need a user login. Unix machines do
              require a Login. The Quarterdeck RSH does not support
              passwords currently, so a generic user account without a
              password should be used. If you encounter problems with
              setting up an account with a nul password refer to the
              paragraph below concerning Unix Configuration. In an
              environment where allowing users to login to the system
              without passwords could cause potential security issues,
              refer to the paragraph below concerning DOS and Unix
              networking.

<application> Corresponds to the application to run on the above
              mentioned <HOST>. The <user> must have rights to run that
              application. If the application's directory is not in the
              path then the full path must be specified, for example:
              /usr/src/demo/ico


<display>     The display variable sets the the node (<HOST>) that the
              the applications display output should be routed to.

 The completed line in this case should read as follows;

rsh sgi4d markw /usr/src/demo/ico -display mink:0

 It is imperative that the RSH.EXE in C:\DVX directory be used as
opposed to using the RSH.EXE in C:\FTP directory. If the C:\FTP
directory is in the path and C:\FTP\RSH.EXE hasn't been renamed or
copied to an obscure directory, running RSH inside DESQview/X may not
quite return the results anticipated. RSH relies on a substantial amount
of variables, the tests mentioned in the previous paragraphs should have
eliminated these variables. To run a DOS client from a DESQview/X
machine, the Program Information File (PIF, distinguished by its ".dvp"
extension) for the relevant application must be in the DVX\DVPS
directory. This is a security feature built into to the DESQview/X
network server.                                                                                                                                                                   Any real mode DOS text

Any real mode DOS text application when run under DESQview/X becomes an
X Client. DESQview/X has the capability to virtualize real mode DOS graphics
applications but this feature has not been implemented yet.


Unix Configuration.

 To be able to RSH a remote machine by using the host name as opposed to
calling an IP address, the file /etc/hosts needs to contain the IP
address and the unique hostname. The host tables on all networked
machines must correspond for the various TCP/IP utilities to work. There
is an example host file in the paragraph titled "Some general notes
about TCP/IP networks". The IFconfig utility could be used to display
the configuration for a particular network interface or with the <-a>
option it will display addressing information for all of the active
network interfaces. <NETSTAT> is another network utility that can help
show the status of the network connections on a particuler machine. Some
ports of System V Release 4 do not allow a nul password account by
default. This can easily be changed by setting the line PASSREQ=NO in
the file etc/default/login.


DOS and UNIX Networking.

 For remote computing to succeed, the X servers must be configured and
started on both Unix machines and DOS machines running DESQview/X. The
DOS machine should be able to pass all of the tests mentioned in the
paragraph regarding "Testing PC/TCP" from within DESQview/X. The Unix
machine should be able to do the same from within its own X environment.
Depending on the the users login script, the X server will be initiated
differently. If the X server isn't called from the startup script then
there is usually an XINIT routine that can be called from the root and
is available to most general users. Some subtle difficulties may occur
if the users rights aren't correctly setup, a very common symptom of
this is that the X server starts up correctly but there is no window
manager. The users startup information can be found in the
/usr/home/.profile file. A typical example of .profile is shown below;

TERM=vt100
export TERM
DISPLAY=unix:2
xinit

 Once the X server has started up correctly on the Unix machine, the user
should grant all rights to the X server from any remote host by issuing
the following command:

 xhost +

 Now the RSH command can be tried between machines. This syntax is
demonstrated above in the paragraph entitled "DOS to DOS networking".
A useful first application to try to run remotely would be Xterm, which
is usually in the /BIN directory, as demonstrated below in the path;

rsh <host> <user> <path> <xterm> -display <display>:0

becomes:

rsh dec333 xuser /bin/xterm -display sgi4d:0

 If security is an issue, and allowing users access to the network
without passwords is unacceptable, then calling Xterm with the
<-e login> parameters will call up a remote Xterm with a login prompt.
For this the users would be logging into a generic account with very
limited access to any system resources. Then they could then login with
their account name and access the remote machine with their own specific
account restrictions. The only disadvantage to this method of
maintaining security this that there is an overhead of one socket for
each Xterm to contend with, for this refer to the above paragraph
entitled "Configuring DESQview/X". The syntax for this would be as
follows:

rsh dec333 xuser /bin/xterm -e login -display sgi4d:0

 This could be encapsulated into the DESQview/X menu. Therefore
eliminating potential user intervention. Unix also allows machines to be
configured for remote access without a user password being specified by
making a file called .rhosts in the usr/home directory. In this file
enter the remote IP address and the remote <host> name. This allows
anyone to login from that machine without a password. Access rights can
be restricted at the local machine level or the user login names can be
added to the .rhosts file. This will only allow the users listed in the
.rhosts file to remote login.