Remoting with Firewall tunneling
This article is taken from content omitted during technical review of the a book entitled Network programming for .NET
(Buy at Amazon UK)
(Buy at Amazon US)
It can be very misleading to say Remoting can tunnel
firewalls. It can, in one direction only! If your object if hosted in a stub
network, there isnít a hope that anybody on the Internet can use it.
There is an open-source bi-directional TCP channel
available from www.ingorammer.com
which properly implements firewall tunnelling in both directions. It uses
persistent connections, with no requirement for an external message store.
However, space constraints prevent the class in its entirety to be published
in this book.
The sample application provided in this chapter uses
remoting in preference to a socket based implementation to simplify the code,
and not out of necessity. Data sent between peers, is temporarily stored in a
database. Any code that can execute arbitrary SQL statements against a
database could be used to implement the peer in this instance.
Implementing a firewall tunnel
The system in mind is an inter-network file transfer P2P
system. With this, users on one stub network, will be able to retrieve files
from computers on a separate stub network, with the help of a Server, which
has a public IP address.
The server maintains a database, which contains all the
requests and responses made by peers. Peers will be able to call methods on a
remote object that can run queries against this database.
To transfer a file from one peer to another, this is the
Peer A, sends a request to the
server, for Peer B to send a file.
The server stores the request in the
Peer B, asks the server to check if
there are any new requests for files.
The server tells peer B that Peer A
wanted a file
Peer B sends the file to the server.
Peer A asks the server if the file
has been uploaded yet.
The server returns the file to Peer
From this specification, we can see what methods are
required of the remote object
public void postRequest(string requestingPeer,
††††††††††††††††††††††† string respondingPeer)
public void postResponse(string
respondingPeer, string filename,
†††††††††††††††††††††††† string fileContents, string
public string checkRequests(string peer)
public string checkResponse(string
respondingPeer, string filename)
Sub postRequest(ByVal requestingPeer As String, _
ByVal filename As String, ByVal respondingPeer As String)†† †††††††††††
Sub postResponse(ByVal respondingPeer As String, _
ByVal filename As String, ByVal fileContents As String, _
ByVal requestingPeer As String)
Public Function checkRequests(ByVal peer As
String) As String
Public Function checkResponse(ByVal
respondingPeer As String, _
ByVal filename As String) As String
In the P2P world, everything is asynchronous. This means
that there is an indefinite time period between one peer calling postRequest
and the recipient peer calling checkRequests. Therefore to hold the data
temporarily between posts and checks, we may use a database.†
A detailed description on how to create an
Access database is described in chapter 2.
The database can also be developed. It should contain two
the former containing fields id (auto number), requester (text), filename
(text). The latter containing fields id (auto number), requester
Save the database as c:\filetransfer.mdb