For those of you that don't know about this technology yet -- you are going to love it once you figure out what it can do and how easy it is to do it. All of the technology built on top of sockets is amazing.
In these examples we will use the Microsoft Winsock control. In actual use we would recommend a third party control from either Mabry or Catalyst since they have more functionality, more debugging features, better tutorials and documentation.
Any two computers that are connected across a network can communicate using windows sockets. The rule of thumb is "First ping it -- then you sock it".
It would be a waste to go off in a long explanation on TCP/IP, Windows Sockets (Winsock), ethernet and all of that. There are too many good resources already out there on the web for us to repeat it:
Other resources include:
You create one server and one client. The server "listens" for incoming connections and the client requests a connection. After the client and server connect, they send messages back and forth and all of the communications "hard stuff" (technical term we picked up during many years of schooling) happens transparently. No protocols, checksums, retries, dividing long messages up into packets, reassembling the packets -- none of the "hard stuff".
All you need is two computers connected to a network. The computers need the TCP/IP protocol enabled. You need to know the IP address of each computer. You can either look this up on your computer or you can run our demo programs which will give you the local IP address and local name.
It can be hard to know your IP address if you are using a DHCP server. To determine if your computer is configured and what it's IP address is -- use the "IPCONFIG" command at the DOS prompt. For example, my computer the screen looks like:
To ping a computer means that you want to verify that the computer is on the network at the specified IP address. The easiest way to ping is to go to the DOS prompt and type the command "Ping X.X.X.X" where X.X.X.X is the IP address of the computer that you want to communicate with. For example, I am running Windows 2000 so I select the "Command Prompt" (instead of MS-DOS Prompt) and enter "ping 127.0.0.1". The screen looks like:
If I enter the command "ping 192.168.1.1" then I get the same response:
Because 192.168.1.1 is the IP address for my computer and 127.0.0.1 is the universal IP address meaning "my computer". If you can ping your own computer it tells you that your computer is configured for TCP/IP. What you want to do now is ping another computer to see if you can communicate with it before you try to connect. You ping the remote computer the same way "ping X.X.X.X" where X.X.X.X is the IP address of the remote computer.
Once you can ping your own computer and the remote computer you are ready to try to connect with sockets.
The Poor Man's Ethernet Instant Messenger is a simple client and server. The server "listens" for a connection request and the client connects. Then the two programs can pass data back and forth. First run both programs on the same computer and on the client side connect to "127.0.0.1" which means your own computer. Make sure both client and server are using the same port number (this should already be configured for port 1001 so don't change it unless you already have some program using port 1001). Once the programs are working on the same computer move them to separate computers (that are networked) and run them again. Make sure that you can ping the other computer before trying to run this program. Click here to download the Poor Man's Ethernet Instant messenger.
In most cases you can have more than one client and the server can broadcast to all sockets. The server always listens for connections on the first socket and hands off the connection to higher numbered sockets.
The poor man never had it so good -- now he's got his own chat room software! In this case the server has multiple clients (visitors to the chat room). When one client sends in a message to the server, the server rebroadcasts the message back out to the clients. Click here to download (this is not yet completed).
Instead of TCP you can use UDP. This is not as reliable as TCP but it uses less overhead. For example if your application already includes checksum and other transmission error handling then you might use UDP since TCP would duplicate the error checking and other overhead.
Now that we've had some fun let's look at how we can use sockets to do real work. The biggest limitation of sockets is that it only transfers one type of data at a time. The way to get around this is to create user defined data types (structures) that describe your data and then convert this data to byte data using the API call CopyMemory. Click Here for more information from Microsoft. Click here to download our example (this is not yet completed).
You will find a lot of different technologies available to you to provide the same functionality. For example, suppose you create a SCADA system that is collecting a lot of information about a process. How do you share that data with the other engineers and managers in the plant? A lot of people are embedding web servers in their SCADA system. This is not a bad idea and there are multiple ways of doing this. For example Windows NT and 2000 have Internet Information Server (IIS) built-in. Or you could add web server software such as Apache. Or you could buy the web server control from Mabry.
But a SCADA system is already heavily burdened with running a lot of code and does not need the additional burden of running IIS or Apache. And now you have to go maintain and program a web server in addition to the SCADA system. What you need is a simple and low overhead way to share data.
What if you included in your SCADA system a winsock server that uses user defined data types? That would require the least amount of overhead (additional burden) on your system. Then you can create a Client in Visual Basic or C# that has a windows socket that connects to your SCADA system, reads the data, and displays the data for the user. If you put the VB client on a file server, then the IT / MIS people will take care of the security issues and you only have to update one copy of the VB client that everybody loads and runs.
This is the architecture that we typically employ in systems. We have one SCADA system per process with a windows sockets server embedded. The SCADA system can tell you everything you need to know about that process. The SCADA system integrates all information in that process. Then instead of an engineer or manager having to go to the SCADA computer, you create a VB client for each SCADA server that connects with the SCADA server, reads the sockets data and displays the data. The SCADA server can broadcast new data to every client once a minute or whatever minimum update time is desired.
This solution minimizes the burden on the server, minimizes network traffic, requires that you only need to create one client for viewing the data, uses the network security but everyone can view the data from their office, home, other plants, around the world -- where ever the network (dial-up) is accessible. You can even use "blade" computers around the plant that connect to the file server and run your VB client. Note that this architecture and functionality is the exact same as an intranet web server and client except a lower burden on your resources and easier and faster development -- you don't have to maintain and program a web server.
Once you get the hang of sockets, go over to Mabry and Catalyst and check out all of the other things that you can do with similar technologies. For example, they have controls for Ping, sockets (improved over Microsoft versions), reading and writing e-mail, searching the internet, browsing the internet, reading the time from the Naval observatory atomic clock, File Transfer Protocol (FTP), and more. The technology is amazing.
One interesting thing that we do is use Visual Basic or C# and a browser control to gather ("mine") information using websites on the internet. For example, suppose you have a lot of suppliers, and you want to sort them by how close their office is to you. You can lookup straight line distance but that is never a good indicator of driving time. You could go to www.mapquest.com and figure out how mapquest generates queries to its "driving directions". Then you can generate a query for each supplier and parse the data that is returned to get the actual driving distance and time.
Another Visual Basic / C# - winsock example people use a lot is collecting stock information. You figure out the query to return stock information from your favorite site. Then you execute this query which returns a string of html data. Then you parse the string of data to extract the data you want.
We try to offer a fair and balanced opinion on every page of our website. We would appreciate more information from other users to express their opinions which we will then incorporate. If you have questions or comments please post them on our message board (see button in left hand column) so that others can read and benefit.
