What classes do I use to create a web proxy

[Peter]

Firstly let me be very clear about this, I do not want to create a web
service proxy nor do I want to do anything with web services.

Basically, I have a shrink wrapped desktop application which downloads
data from a web site. Unfortunately the application has a fixed
timeout and the web server regularly exceeds this, causing the
application to shut the connection and subsequently not receive any
data. The desktop application also uploads data to the web server but
this does not suffer from timeout problems.

Changing the desktop or web serve application is not an option.

So I need to create a lightweight proxy that can sit between the
desktop and web server applications. The proxy needs to operate in 3
modes. The 1st mode would download the data from the web server to
persistent storage and the 2nd mode of the proxy would serve this data
from persistent storage to the desktop application. To complicate
matters a little more, the 3rd mode must be able to operate as a
transparent proxy, merely accepting the data fromthe desktop
application and passing it on to the web server.

So I think that I simply need to be able to request the data from the
web server and provide a web server interface to the desktop
application. I know how to do this quickly in Java but have no idea
where to start with dotnet. The documentation in MSDN is somewhat
overwhelming at the moment.

Can anyone please give me a pointer to the classes that I would need
to do this. Of course I may also be off target here, so if I need to
use Visual C++ instead of C#, then please point that out.

TIA, Peter

 

[Alberto Poblacion]

Take a look at the System.Net.Sockets namespace.
You could use a TcpListener object to listen for requests from the desktop
application, and a TcpClient (or easier: a WebRequest object) to connect to
the original web server.

However, there might be an easier way: You could use an asp.net application
hosted in IIS to receive the requests from your client. An Http Handler in
your application would process all requests, and use the WebClient class to
send the same requests to the original webserver. This would save you from
programming all the multithreading that you would need to add into your code
if you were using a TcpListener to process mutiple client requests.

You say that you "do not want to create a web service proxy nor do I want to
do anything with web services". However, this route that you don't want to
follow might be the easiest of them all. If all the requests from your
desktop client are calls into a web service, you can probably, with a bit of
work, use asp.net web services to emulate the services in the original
server, and also use the web service client in .Net to call into the server.

 

[Peter]

Take a look at the System.Net.Sockets namespace.
You could use a TcpListener object to listen for requests from the desktop
application, and a TcpClient (or easier: a WebRequest object) to connect to
the original web server.

However, there might be an easier way: You could use an asp.net application
hosted in IIS to receive the requests from your client. An Http Handler in
your application would process all requests, and use the WebClient class to
send the same requests to the original webserver. This would save you from
programming all the multithreading that you would need to add into your code
if you were using a TcpListener to process mutiple client requests.

You say that you "do not want to create a web service proxy nor do I want to
do anything with web services". However, this route that you don't want to
follow might be the easiest of them all. If all the requests from your
desktop client are calls into a web service, you can probably, with a bit of
work, use asp.net web services to emulate the services in the original
server, and also use the web service client in .Net to call into the server.

The reason I say I don't want to use a webservice proxy is because
lately it seems whenever you mention anything about the internet,
people assume you are using webservices. Unfortunately in this case, I
am interfacing in to a legacy application that knows nothing about
webservices, it's a simple cgi.

As for a tcp listener, the desktop application makes a https call, so
I would not be able to use a simple tcp listener in this case as I
need to examine the packet coming in. I was hoping there was a
lightweight class for doing this, other than using IIS, which would
make it slightly more complicated for the non technical clients. Guess
I'll have to bite the bullet and use IIS after all, thanks for your
help.