Click here to Skip to main content
Click here to Skip to main content
Add your own
alternative version

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

, 23 Feb 2002
A set of socket libraries for writing distributed computing applications over the internet
socketpro.zip
netdemo
ClientComponents
MultiSvsSample
SvrComponents
bin
include
lib
Samples
client
DnsSvs
GetHTML
InternetIO
MultiSvsSample
SpeedTest
res
DResolver
Svr
NormalApp
NTSvs
help
trash
SecureSocket
SafeSocket
DNSResolver.exe
GetHtml.exe
IONet.exe
MultipleSvs.exe
MultiSvs.exe
MultiSvsClient.exe
NetBaseR.dll
SafeSocket.exe
SecureSocket.exe
SpeedTest.exe
ClientSocket.dll
DResolver.dll
SBroker.dll
SockFile.dll
fundamental.gif
patterns.gif
NetBaseR.lib
DNSResolver
DNSResolver.vbp
DNSResolver.vbw
frmDNSResolver.frm
frmDNSResolver.frx
frmChatClient.frm
frmChatClient.frx
GETHTML.vbp
GETHTML.vbw
iIO.frm
IONet
IONet.vbp
IONet.vbw
frmMultiSvs.frm
frmMultiSvs.frx
MultiSvs.vbp
MultiSvs.vbw
SafeSocket.vbp
SafeSocket.vbw
SecureSocket.frm
SpeedTest.ico
SpeedTest.aps
SpeedTest.clw
SpeedTest.dsp
SpeedTest.dsw
dlldata.obj
DNS.rgs
DResolver.aps
DResolver.def
DResolver.dsp
DResolver.dsw
DResolver.opt
DResolver.plg
DResolver.tlb
DResolverps.def
DResolverps.exp
DResolverps.lib
DResolverps.mk
DResolver_i.obj
DResolver_p.obj
MultipleSvs.dsp
MultipleSvs.dsw
MultiSvs.dsp
MultiSvs.dsw
MultiSvs.rgs
MultiSvs.tlb
MultiSvsps.def
MultiSvsps.mk
dlldata.obj
SafeSocket.aps
SafeSocket.dsp
SafeSocket.dsw
SafeSocket.plg
SafeSocket.rgs
SafeSocket.tlb
SafeSocketps.def
SafeSocketps.dll
SafeSocketps.exp
SafeSocketps.lib
SafeSocketps.mk
SafeSocket_i.obj
SafeSocket_p.obj
SPassword.rgs
MultipleSvs.exe
MultiSvs.exe
NetBaseR.dll
SafeSocket.exe
<html>

<head>
<title>Use of SocketPro for creating non</title>
<meta name="GENERATOR" content="Microsoft FrontPage 3.0">
</head>

<body>

<h3 align="center"><strong>Use of free SocketPro package for creating super client and
server applications</strong></h3>

<p align="center"><strong>Yuancai (Charlie) Ye<br>
<a href="mailto:yekerui@yahoo.com">yekerui@yahoo.com</a></strong></p>

<ol>
  <li>Introduction<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Currently, most of people use
    MS DCOM/COM+, Java Bean/RMI, and Corba to do distributed computing over internet. All of
    technologies are provided with somewhat tools and intermediate objects to simplify
    internet development. However, these technologies have one common and fundamental problem
    that all of 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 logical.
    Additionally, I also doubt that these technologies are able to really move data across
    internet efficiently.</p>
    <p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Recently, I have time to create a framework
    package, named as SocketPro, on socket for writing distributed computing applications over
    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 dlls and other help articles will be provided at the site of <a
    href="http://www.geocities.com/oledbpro">UDAParts</a>.</p>
    <p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; All of applications developed from this
    framework will have the following BIG BIG BIG .... advantages plus other numerous
    advantages:<br>
    <ul>
      <li>Non-blocking/blocking, parallel computing client and server.<br>
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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, 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.<br>
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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. <br>
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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.<br>
        <br>
      </li>
      <li>Both client and server run at the fastest speed because of Nagle algorithm.<br>
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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.<br>
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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.<br>
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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.<br>
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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.<br>
        <br>
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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).<br>
        Software: Client -- Win95; Server -- NT 4.0 Server.<br>
        <br>
        Table 1. Speed comparison among different methods with the average of 1000 calls. <table
        border="1" width="100%">
          <tr>
            <td width="20%">&nbsp;</td>
            <td width="20%">Asyn/Batch</td>
            <td width="20%">Asyn/Nagle</td>
            <td width="20%">Syn/OneByOne</td>
            <td width="20%">DCOM</td>
          </tr>
          <tr>
            <td width="20%">Speed AutoDetect (100 Mb/10Mb Full-Duplex)</td>
            <td width="20%">7-45</td>
            <td width="20%">4-7</td>
            <td width="20%">2.3</td>
            <td width="20%">1 (2.5 ms/call)</td>
          </tr>
          <tr>
            <td width="20%">10Mb Full-Duplex</td>
            <td width="20%">9-52</td>
            <td width="20%">28-60</td>
            <td width="20%">1</td>
            <td width="20%">1 (25.5 ms/call)</td>
          </tr>
        </table>
        <p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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.<br>
        <br>
        </p>
      </li>
      <li>Cross-platform data communication and cross-language development.<br>
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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. <br>
      </li>
    </ul>
    <p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Other advantages includes:<ul>
      <li>Fast connection to a server.</li>
      <li>Quick initialization of a class object.</li>
      <li>Simple installation and security setup.</li>
      <li>Easy creation of server application specific authentication mechanism.</li>
      <li>Simple to learn and use, and no complicated concepts are involved.</li>
    </ul>
    <p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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.<br>
    </p>
  </li>
  <li>Setup of test server and client applications<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    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. </p>
    <p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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 -&gt;Settings-&gt;Control
    Panel-&gt;Services-&gt;MultiSvs from NT platform. If you use the platform other than NT,
    you could follow the similar steps to start it.</p>
    <p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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&nbsp; ..\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.</p>
    <p align="center">&nbsp;</p>
  </li>
  <li>Functionalities of demo client and server applications<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Here is the list of functionalities available
    from the demo server application:<ul>
      <li>Exchange files between a server and clients.</li>
      <li>Remotely access files in a server.</li>
      <li>Provide a socket proxy/broker service on behalf of clients to process various command to
        other servers.</li>
      <li>Provide host name resolving service.<br>
      </li>
    </ul>
    <p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Here is the list of functionalities
    available from client components:<ul>
      <li>ClientSocket.dll:&nbsp;&nbsp;&nbsp; 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.</li>
      <li>SockFile.dll:&nbsp;&nbsp;&nbsp; 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.</li>
      <li>SBroker.dll:&nbsp;&nbsp;&nbsp; You can use it to execute all of protocol commands
        through the demo server application.</li>
      <li>DResolver.dll:&nbsp;&nbsp;&nbsp; You can use it to do DNS resolving through the demo
        SocketPro server application. </li>
    </ul>
    <p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Here is the features of the demo client and
    server applications:<ul>
      <li>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. <br>
        <br>
      </li>
    </ul>
  </li>
  <li>Source code<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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). <br>
    <br>
  </li>
  <li>Notes<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; All of applications included with
    this particular package are free with the following limitations:<ul>
      <li>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.</li>
      <li>The file ClientSocket.dll is hard-coded to support 2 socket connections only from one
        client application.</li>
      <li>The client COM dlls, SBroker.dl and DResolver.dll, are totally free to you.</li>
      <li>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.</li>
      <li>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.</li>
    </ul>
    <p> If you need us to do something for you, give us your message using email <a
    href="help/yekerui@yahoo.com">yekerui@yahoo.com</a>. Service is available now!</p>
  </li>
</ol>
</body>
</html>

By viewing downloads associated with this article you agree to the Terms of Service and the article's licence.

If a file you wish to view isn't highlighted, and is a text file (not binary), please let us know and we'll add colourisation support for it.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

Share

About the Author

Yuancai (Charlie) Ye
Web Developer
United States United States
Yuancai (Charlie) Ye, an experienced software engineer, lives in Atlanta, Georgia. He is an expert at OLEDB consumer and created a powerful data accessing libarary at the site http://www.udaparts.com. He has been working at SocketPro written from batching, asynchrony and parallel computation for more than three years. Visual C++, C# and ASP.NET are his favorite development environments.

| Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.150123.1 | Last Updated 24 Feb 2002
Article Copyright 2002 by Yuancai (Charlie) Ye
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid