Introduction

The widespread use of firewalls has impacted the free-wheeling deployment of socket based applications.  Still, if there were a way to pass communication requests through port 80, the Internet port, a good amount of TCP/IP Socket programs might still work.  A couple of approaches might provide such a solution.

  1. Provide a server that receives via sockets and uses HTTP to send data to a partner sever.  When the server receives data from the HTTP port, it passes it on to other programs within its Intranet using sockets.
  2. With the advent of .Net, there is another simpler alternative.  Provide a web service behind a firewall.  That service can be “discovered” by outside applications.  Communication from applications outside that service’s Intranet is handled by the .Net infrastructure.  And the call to it is simply a method call specifying parameters that tell the service what to do.  The web service can communicate with other programs using sockets.

 

The remainder of this paper, discusses an application of the second alternative.

 

A Web Service Socket Portal

 

A Web Service is by far the easiest way to implement an HTTP Portal.  Download the sample.

 

 

  1. Client (finding Service through discovery) calls the Web Service Portal.
  2. Web Service uses message descriptor to pass the message on to target using provided socket class
  3. Target process uses provided socket class to receive message and return reply if required
  4. Web Service receives the message and returns it to the originating application
  5. Client receives reply.

 

Message Descriptor

A message is passed to the Web Service with a message Descriptor. 

 

 

Byte

length

Name

0

100

TargetName - URL or Computer name of socket target of received Message

100

4

Port - target port on target URL

104

4

RcvTimeOut - ms to wait for reply (0 if reply not expected)

108

2

WaitForReply - True if wait for reply. False if reply not expected)

110

2

Loopback – True if loopback from the service.  False, go to application.

112

4

SndLength - length of message to send

116

4

MaxRcv - max length to be received (0 if reply not expected)

120

4

RcvLength - length of received reply

 

Target Name and port are obvious fields.  The target application must be running in the local Intranet as a Socket server waiting on that port to receive messages.  The SndLength field is the length of the message associated with this Descriptor.

 

The four receive fields pertain to any reply that might re returned.

 

Loopback is included for testing access to the Web Service.  Loopback is set true in the Descriptor, the associated message is not passed through socket so an application program.  Instead, it is sent immediately back to the originating application.

 Sessions

Sockets is state oriented and sessions are maintained.  Once a client connects to a server, messages can be exchanged to the exclusion of other callers.  Implementing a Web Service acting as a portal between two environments could maintain such a relationship. However, depending upon the volume of messages, keeping the service tied up in one session would not be a good idea.  A reasonable alternative would be to allow sending one message and receiving one reply.  This would probably handle over 80% of application requirements.

Client and Server

While not implementing the socket protocol, the originating application would functionally be a client.  The target application would be the server.  The Web Service Portal resides between the two and acts as a socket client proxy for the application client.  It connects to the application server as a client.

MEsktPortal

Macy Enterprises provides a web service that functions as a socket portal.  The distribution contains

  1. The web service
  2. A test client application
  3. And a test server application
  4. A simplified sockets class
  5. A message descriptor class

Installation

Download the self-extracting zip file

  1. Extract the contents
  2. Copy the MEsktPortal folder to your server
  3. Edit Web.config changing the value for trialFile to the server relative path
  4. Set the security for the sktTrial file giving the ASP.NET account Full control
  5. Open the ApplClient solution
  6. Remove any Web Reference in ApplClient
  7. Right Click references in ApplClient in the MsgDescriptor solution and add a Web Reference.
  8. Search for MEsktPortal and add it.
  9. Run ApplClient in the MsgDescriptor solution
  10. Run ServerTest

 

MEsktPortal, MsgDescriptor, and MEsockets come as DLL’s.  The solutions for these are also included.  However, the MEsktPortal solution does not include the source code for the Web Service.

 

The ServerTest button should be pressed before any message is sent from ApplClient without Loopback=true.  ServerTest will run as a server, wait for a message, return the message, and close the connection.  The button must be pressed again to re-initiate this process.

 

When downloading the production version, the source is also included as part of the MEsktPortal solution.

 

Execution

When installed as above, the MEsktPortal Web Service resides on a server and has a URL defining its location.  Know what this is.  When testing on a local machine, the URL would be something like “http://localhost/sktPortal/MEsktPortal.asmx”.  When searching for web references as above this is what will be displayed:

 

 

Double clicking the desired service will add it to your project.  Do this for the MsgDescriptor solution’s ApplClient project.  ApplClient should be selected as the startup project in the MsgDescriptor solution.  It is the screen that generates a test message to be passed to the portal Web Service.  When running this solution, the following screen appears.

 

 

Look at the source code to see how the Web Service is called and how the descriptor is set up.  With Loop checked, any message entered at step 2 is sent to the service and the service will immediately echo the message back bypassing any socket calls.  The returned message is displayed following step 3.  Any errors are displayed in the error box.

 

Before trying to send via sockets to the test server, be sure to run the ApplServer solution and check the NoLoop radio button.  With Wait checked, the service will wait for a reply from the target process. ApplServer is coded to send a reply.  If NoWait is checked, the Service closes the connection after the message is sent.  (See the Data Communications Tutorial for a discussion of the importance of providing an Ack/Nak protocol to guarantee delivery of messages.)  The ApplServer form looks like this.

 

 

Simply enter the port (which should be the same as the port on the ApplClient form) and press the button.  When a message is received, it will be displayed in the message box.  Status of the program is written to the right of the button.  Each press of the button will handle one exchange of messages.