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!
