Each computer must also be running some software that uses the same "protocol stack". For our purposes here, we can simply say that each computer must be running some software that uses the sockets library. For example, perhaps you will write a REXX script that uses RexxSock, and you'll run a copy of this script on each desired computer on your network. This script will be designed to communicate with itself (ie, pass data among the desired computers that are running this same script).
Note: Your script can communicate with any software, written in any language, that happens to also use a sockets library. You are not restricted to communicating only with another REXX script using RexxSock. Of course, you do need to be aware of what specific data the other software expects you to send, and what data that other software may send back. This will likely be documented somewhere in that other software's programming information.
A socket
In order for your REXX script (running on one computer) to be able to use the RexxSock functions to connect to another computer and send it some data, your script will first need to obtain something known as a socket. Conveniently, there is an RexxSock function you call to obtain one of these sockets (ie, SockSocket). You will then pass this socket as an argument to most other RexxSock functions.
So, what is a socket? It is not important for you to know the details of what it is. You need understand only what a socket is for. Think of a socket as a telephone. A telephone enables you to "call" some other person who also has a telephone. You call that person by knowing, and dialing, a specific phone number assigned to that person's phone. That person hears his phone ring, and he answers the phone. At that point, the two of you are "connected", and you can exchange information, until one (or both) of you "hangs up". A socket does likewise, except that it is two computers involved in this "phone call" instead of human beings, and the two computers use sockets instead of telephones.
Client and server
We usually refer to the computer that initiates the "phone call" (by "calling" some other computer) as the client computer. We usually refer to the computer that is waiting for the "phone call", and answers the phone when it "rings", as the server computer. A server need not be a mainframe computer. It could be a desktop computer. And the client computer need not be a desktop computer. It could be a mainframe. The important thing is that the client is the one that calls the other computer, and the server in the one that answers the other computer's call. Otherwise, the words "server" and "client" do not imply anything else about a computer.
IP address and port number
Just like every telephone has a unique "phone number" assigned to it, every socket must have a unique "network number" assigned to it.
The first part of this number is refered to as the IP address. This is usually written as four decimal numbers separated by periods. Examples of an IP address are 192.8.100.10 and 188.1.200.16. Each computer on the network will have its own, unique IP address. So when your script (running on that computer) creates a socket, the first part of its unique "network number" will be that computer's IP address. When your script wants to communicate with another computer, you will need to know that other computer's IP address. (Later, we'll discuss how to determine that).
Note: It is possible for a single computer to have several IP addresses. But typically, one IP address will be its primary one. On your home computer, you would have chosen your desired IP address when you set the TCP/IP properties for your network card.
The second part of a socket's unique network number is the port number. It is entirely possible to create numerous sockets on one computer, but each socket must have a different port number. Think of a port number as a telephone extension number. Why would you have more than one socket on a computer? For the same reason that you may have numerous telephones in an office, each on a different extension. Your office may have two salesmen. One guy sells refrigerators. Another sells paper clips. A customer wanting to buy a refrigerator doesn't want to talk to the paper clip salesman. And a customer wanting to buy paper clips doesn't want to talk to the refrigerator salesman. So, even though both customers may call the same business number, there are two different extensions for the two salesmen.
Think of your server computer as that one business office. Its IP address is like the business phone number. Client computers will use this one IP address to call your server computer. Assume that you want to simultaneously run two of your scripts on that one server computer. One script allows clients to exchange data relating to desktop/registry settings. We'll name this script "Desktop.rex". The other script allows clients to exchange (ie, stream) audio data. We'll name this script "Audio.rex". These two scripts have entirely different functions. (Now, it's possible to create one script that handles both functions, but let's assume that you don't want this, because perhaps sometimes you may run one or the other script and therefore want them to be functionally separate scripts). The client that wants to stream audio data doesn't want to talk to the "Desktop.rex" script. And the client that wants desktop data doesn't want to talk to the "Audio.rex" script. So, Audio.rex and Desktop.rex will each create its own socket, each with a different port number. Therefore, the client that wants to stream audio data will use the server's IP address, and also use the port number for the socket that Audio.rex created. The client that wants desktop data will use the same server IP address, but use the port number for the socket that Desktop.rex created. (And yes, those clients will need to know what those port numbers are. So, you will need to design your scripts with careful choice of port numbers, or allow the enduser to specify the desired port number in your scripts. Some port numbers may already be reserved by the operating system for certain networking use, so choice of port number should not be totally arbitrary).
In this way, Audio.rex will not even see the data sent by the client that wants desktop data. And Desktop.rex will not see the data sent by the client that wants audio data. Even though all data may be coming over the same network connection, RexxSock knows how to separate it out to the two ports, so that Audio.rex receives only the data a client sent to Audio.rex's port, and Desktop.rex likewise receives only data sent to its own port. And of course, the data that Audio.rex sends out will be sent only to the client that wants audio data (ie, not the client that wants desktop data).
So, IP addresses and port numbers are used to keep data separate for several networking programs all running on the same network and/or computer, and thereby prevent them from interfering with each others' transmissions.
Domain names and IP address
IP numbers are difficult for humans to remember. We find it a lot easier to remember words and names. So, a domain name (or "TCP/IP alias") was created for each IP address. An example of a domain name is "www.microsoft.com". That's a lot easier to remember and type into your browser's address bar than the IP address for microsoft's web site (which would be an IP address like 192.8.100.10 -- I don't even know what the actual IP address is).
Think of a domain name like a name in a telephone book. You look up the name "Bill Gates" in the telephone book, and discover that his phone number is 555-0666. So too, when you type the name "www.microsoft.com" into your browser, your browser looks up the IP address for that name. Of course, your browser doesn't have a "phone book". Instead, it connects with some special computer(s) on the internet, passes them the name, and they return the appropriate IP address for "www.microsoft.com". Your browser can then use a socket to connect to some port on the Microsoft server associated with that IP address.
Your script can also utilize this. RexxSock has a function that you call (ie, SockGetHostByName), passing a domain name, and it returns the appropriate IP address. If the domain name is for some computer on the internet, RexxSock may need to connect to some server on the internet to get that IP address. If the domain name is for a computer on a local network, then RexxSock should already have that information on the computer (if you have set up your local network properly. For example, if you have two home computers connected via ethernet, you likely have setup "My Network Places" or "Network Neighborhood" on each computer so that each knows what unique name you chose for the other computer).
Since a single computer may have more than one IP address associated with it, SockGetHostByName may fill in a stem variable with several domain names (ie, one for each IP address), but typically you'll use the very first IP address, which should be the primary one.
Note: If you know a computer's IP address, and wish to determine its domain name, there is another RexxSock function to do that (ie, SockGetHostByAddr).
Besides needing to know the IP address of the other computer, your script may also need to know the IP address of its own computer. RexxSock has a function you can call to determine the latter (ie, SockGetHostId). SockGetHostId will return the IP address of the computer upon which your script is running.
Server script
A server is the computer that sits by the "phone", and waits for someone to call. Your server script will first need to create a socket on a specific port number (that it expects other client computers to connect to). We'll call this the server socket. You use SockSocket to create your server socket. You can choose any port number you like for your socket, but be aware that certain port numbers may already be in use on the computer, in which case SockSocket will fail.
Then your script will simply wait for a call to come in. Your script calls SockSelect to wait for a client to "call in". RexxSock does all the work of detecting when and if some client calls in on your socket's port. SockSelect will not return until some client has called in, and actually wants to connect to your running script.
Note: If you're using a GUI add-on with the Windows operating system, such as REXX GUI, then instead of using SockSelect, you will use SockASyncSelect.
When your script returns from SockSelect, then you will typically call SockAccept to accept the call. SockAccept will return another socket for the client whose call you have accepted, and tell you that computer's IP address. This new socket (not your server socket) is what you will subsequently pass to functions such as SockSend and SockRecv in order to send data to, or read data from, that client computer. When you're done communicating with that client, you will pass this client socket to SockClose to terminate communication with that one client (ie, "hang up" on that client).
At this point, your script can call SockSelect again to wait for another client to connect.
Note: The above synopsis assumes a server script that allows only one client at a time to connect. As you will discover later, you can lift this limitation. The details will involve a bit more coding, but the synopsis above is still the basic principle of how a server script works.
Client script
A client is the computer that initiates the call to the server. Your client script must know the IP address (or domain name) and port number of the server socket it wishes to connect to. If you're writing both the server and client scripts, and you will be setting up the networking on both computers, then you can hardwire these values into your client script (since you'll be choosing both numbers yourself). Otherwise, you will ask the enduser for at least the domain name of the computer, and the port number to use.
Alternately, if you're connecting to a computer on a local network, you may be able to call some operating system function to get a listing of the names and IP addresses of all computers on that network. Then, you can present those choices to the enduser and let him pick one.
In any event, you definitely will need to know the port number that the server script is using.
To connect to the server, your client script will call SockConnect, telling it the IP address (or domain name) of the server computer, as well as the port number that the server is using to accept connections. RexxSock does all the work of connecting to the server computer's socket. SockConnect will not return until that server has either accepted or refused your call.
Assuming that the server accepts your call, then SockConnect will return a new socket for the server. Your client script will pass this socket to SockSend and SockRecv in order to send data to, or receive data from, the server computer. When you're done communicating with that server, you will pass this socket to SockClose to terminate communication with that server.