Use of free SocketPro package for creating super client and server applications

• Download source files - 282 Kb
• Download demo project - 282 Kb

Introduction

Currently, most of people use MS DCOM/COM+, Java Bean/RMI, and Corba to do distributed computing over internet. All of these technologies are provided with some tools and intermediate objects to simplify internet development. However, these technologies have one common and fundamental problem that all of the calls between a client and a server are blocked for a returned result (please correct me if this is wrong). A client stays still, and has to wait for a while after sending a request to a server. If the request is a lengthy action, the client application seems to be dead to a user. In most cases, we could use a worker thread at the client side to do background computation for solving this problem. However, this comes with an expensive price, more coding, data synchronization and mess in coding logic. Additionally, I also doubt that these technologies are able to really move data across internet efficiently.

Recently, I had time to create a framework package, named as SocketPro, on socket for writing distributed computing applications over the internet, which contains a set of COM dlls and a standard dll (NetBaseR.dll) for EASY development of both client and server applications. In the near future, the documentation for all of the dlls and other help articles will be provided at the site of UDAParts.

All of applications developed from this framework will have the following BIG advantages plus other numerous advantages:

• Non-blocking/blocking, parallel computing client and server.

  In regards to the client side development, this advantages implies that a client is able to send simultaneously multiple requests to a server through either one or multiple sockets for non-blocking and parallel computation. The client GUI components could be NEVER blocked without creating a worker thread. The important point here is that you can achieve non-blocking compuing without involement of threads. All of client function calls, which lead to data movement over internet, can be switched between blocking and non-blocking modes at your will after a socket is created. This is another particular advantage. It is hard to get this feature from other technologies, MS DCOM/COM+, Java Bean/RMI, and Corba.
  In regards to the server side development, this advantage implies that a server application is able to fast and parallel process multiple requests from one or different client machines no matter whether the request is lengthy action or short action. The server is developed with multiple threads and message queues. All of queues are running independently and in parallel. In some cases, the server can be developed so that a quick request can be processed and returned first, even though the request is sent to the server after a request with a lengthy action. The server application groups/clusters various calls and assign them to different queues for processing. In all of cases, all of short requests from one or different sockets are assigned to one queue only, for reduction of involved threads and queues. The server is also able to kill all of idle queues and threads automatically for reducing system resources required and thread context switch. The server is able to detect the dead clients with a ping function.

  You may think that this must be difficult to be implemented. It is true to take me a long time to create this piece of software component. You may think that it is difficult to develop a server and client applications based on this framework because of message queues, multiple threads, data synchronization problems. You are wrong and wrong!!!! Actually, The frame wraps the Winsock 2 library, and automatically manages message queues, threads and data synchronizations for you, and also efficiently by default. All you need to do is that you need to implement your functions, and tell the framework if the function is lengthy action or not. That is all! Attached with this article, you will also find three Visual C++ examples, DResolver (client), NTSvs (Server) and NormalApp (Server), to show you how to write client and server applications from the SocketPro package. You could see how simple to write such cool client and server applications from the SocketPro package.
  
  

• Both client and server run at the fastest speed because of Nagle algorithm.

  At the beginning, I said I doubt if MS DCOM/COM+, Java Bean/RMI, and Corba can move data over network efficiently. Let me tell you a simple reason using a typical example. On an Ethernet network, the MTU for TCP/IP is 1460 bytes. Suppose that a client sockets send 29 requests, each of them with 50 bytes, and get 29 returned data of 50 bytes. If you use MS DCOM, the number of data round-trips will definitely be 29. However, if your server and client applications runs in the non-blocking mode, the Nagle algorithm will come in effect by default. Socket stack will automatically coalesce all of 29 requests into one big stream, and send it onto a server. The server similarly does coalescing and sends all of processed results to the client with one big stream if all of 29 actions are not lengthy action. The number of data round-trips is just one! As far as I know, even though Nagle algorithm may be turned on, all of MS DCOM/COM+, Java Bean/RMI, and Corba can hardly take advantage of coalescing through Nagle algorithm (Correct me if I am wrong) because their functions can't be internally non-blocking. I can hardly imagine these technologies can generically and automatically batch all of function calls into one, and then unpack it into separately calls at the server side.

  Even if your client socket-based application doesn't run in the non-blocking mode, you can batch calls into one by your code. But it is not friendly to do so. There is no way to pack function calls with DCOM/COM+, Java Bean/RMI, and Corba.
  Nagle algorithm is important especially for the server application. Reduction of data round-trips are the most efficient way to improve the server and client application performance, especially when many clients are connected with a server application, and data movement over network is extensive or your network is slow like a dial-up networking.
  Additionally, SocketPro directly talks with Winsock 2 without middle layers. In comparison to MS DCOM with identical protocol and hardware, SocketPro still runs 130 % faster even though SocketPro runs in the blocking mode across machine according to my experiments. In order to show you what performance you can obtain from this SocketPro package, I wrote a sample name as SpeedTest, and compared results with DCOM applications (DCOMSleep and ClientTest). All of sample source codes are provided with this package for your test. Look at the codes and play with samples. Like me, I think you will sign with various feelings after obtaining your performance data! Here is performance result I obtained from my machines.
  
  Hardwares: client -- P133 with 48 RAM; Server -- P700 with 256 RAM; Fast Ethernet 10/100 Network Cards + Ethernet 5-Port Hub (10Mbps) + Two Category 5 100BaseTX Network Cables ($50 totally, LinkSys NC100).
  Software: Client -- Win95; Server -- NT 4.0 Server.
  
  Table 1. Speed comparison among different methods with the average of 1000 calls.

  	Asyn/Batch	Asyn/Nagle	Syn/OneByOne	DCOM
  Speed AutoDetect (100 Mb/10Mb Full-Duplex)	7-45	4-7	2.3	1 (2.5 ms/call)
  10Mb Full-Duplex	9-52	28-60	1	1 (25.5 ms/call)

  Under all of my tests and conditions, SocketPro applications always faster than DCOM. I hope this test data are attractive to you. Running with samples, please give me a message here or privately if you find your result is against with these results. In some cases, if only one request is sent to a server, the speeds among these methods do not change very much. However, the performance with batch or Nagle algorithm will be speeded up if two or more asynchronous calls are called together by reducing data frames over network.
  

• Cross-platform data communication and cross-language development.

  DCOM/COM is limited to window platform only, although MS said DCOM frameworks are available for other platforms. It is hard to find a real DCOM application developed on other platforms. You can use many languages (Java, C/C++, VB, dot.net, etc) from any platforms to develop client socket application to talk with a SocketPro server application, because socket communication is based on binary data and has very low dependency. In regards to a server application from SocketPro, you can only develop it with C++ for the best performance on Win 9x, NT4.0 ME, 2k and XP platforms at this time.
  

Other advantages includes:

• Fast connection to a server.
• Quick initialization of a class object.
• Simple installation and security setup.
• Easy creation of server application specific authentication mechanism.
• Simple to learn and use, and no complicated concepts are involved.

One disadvantage is that a developer must be ready to handle both blocking and non-blocking calls at both the client and server sides. It is involved with more coding for packing and unpacking sending and received data. It is simple and understandable in concept but tedious and more codes. For the best performance and reduction of data trips without help of Nagle algorithm, a developer should try the best to pack data on his or her own instead of Nagle algorithm, because the Nagle algorithm still costs a little time if the machine is not fast. In order to reduce the code of packing, a help class, CPacking, is provided with the package. For how to use it, see the following VC++ samples code.

Setup of test server and client applications

After downloading the socketpro.zip, unzip the package into a directory. You need to set up both client and server applications which are located in the directories of ..\netdemo\clientcomponents\ and ..\netdemo\svrcomponents\, respectively.

To start up the sample server application, you could double click the application MultipleSvs.exe (port # =1741). If your server is NT or its descendents, you could also start a NT service, MultiSvs.exe (port # = 1739). To start the NT service, you should install it by executing the DOS command, MultiSvs -Service. After installing it, you could start it by ->Settings->Control Panel->Services->MultiSvs from NT platform. If you use the platform other than NT, you could follow the similar steps to start it.

To run the sample client application from a Win32 (not CE) platform, you need to register four COM dlls (ClientSocket.dll, SockFile.dll, SBroker.dll and DResolver.dll) at your client machines first, which are located at the directory of  ..\netdemo\clientcomponents\. To test the performance of sample NT server application, you could run multiple applications at one client machine or multiple client machines. Additionally, the sample VB client application and code are provided. See the files in the directory of ..\netdemo\samples\. I hope you like the application and give me your bug reports, questions, suggestions and concerns.

Functionalities of demo client and server applications

Here is the list of functionalities available from the demo server application:

• Exchange files between a server and clients.
• Remotely access files in a server.
• Provide a socket proxy/broker service on behalf of clients to process various command to other servers.
• Provide host name resolving service.
  

Here is the list of functionalities available from client components:

• ClientSocket.dll:    You can use it to build up the connection from a Win 32 platform to the SocketPro server application, and also to all of socket-based applications running on all of platforms. After a connection is set up, you could use it to excute various command either synchronously or asynchronously. Additionally, it also provides functions to do DNS resolving either synchronously or asynchronously at the client side. You can use it independently without prerequirement of other components.
• SockFile.dll:    You can use it to fast exchange files between a server and a client. You can also use it to remotely access files in a server machine through a SocketPro server application. It has all of important functions of Win32 file I/O functions.
• SBroker.dll:    You can use it to execute all of protocol commands through the demo server application.
• DResolver.dll:    You can use it to do DNS resolving through the demo SocketPro server application.

Here is the features of the demo client and server applications:

• You can see the features after testing the attached samples. These features include speed, parallel/non-blocking computing without a worker thread, and simplicity, as well as many others.

Source code

In this package, you can get the source code of all of four VB client applications. In regards to VC++ code, you get the source code of two client applications (SpeedTest and DResolver) and two server applications (NTSvs and MultipleSvs).

Notes

All of applications included with this particular package are free with the following limitations:

• The NetBaseR.dll enables you to build only two client socket connections to a server from a client application. A SocketPro server application only supports accepting 32 client connections only.
• The file ClientSocket.dll is hard-coded to support 2 socket connections only from one client application.
• The client COM dlls, SBroker.dl and DResolver.dll, are totally free to you.
• The client COM dll, SockFile.dll, is free to you except that four functions, ISocketFile::GetFile, ISocketFile::SendFile, and ISocketFile::WriteText and ISocketFile::WriteChunk, are disabled after 60 days.
• Authentication of both server applications, MultipleSvs.exe and MultiSvs.exe, are disabled for your easy setup and testing. You should pay enough attention to security. If not, someone may access your server machine files and manage them through the server application.

If you need us to do something for you, give us your message using email yekerui@yahoo.com. Service is available now!