Peter
Mon May 12 03:07:05 CDT 2008
On May 9, 2:59 pm, "Alberto Poblacion" <earthling-
quitaestoparacontes...@poblacion.org> wrote:
> 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" <pepaltavi...@yahoo.co.uk> wrote in message
>
> news:27fcdd18-2d14-4a6f-ac32-8435ab2ead32@y38g2000hsy.googlegroups.com...
>
> > 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
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.