We Keep Coding

SSE Client request which does not terminate c#

I am using C# to connect to a web service. I am need to send a GET request to monitor some transactions, and the web service will be sending the transactions to me continuously without breaking the connection. The web service provider said I need to connect to them with a http library that supports SSE.
I have tried using HttpWebRequest and HttpClient to send request and receive response, but both of my attempt failed. I don't get response from the web service.
My question is:
The web service will send the transactions to me without breaking the connection, but how do I keep the connection up? Do I have to set up a socket for listen after I send the GET request?
Thank you,
kab

I have the issue resolved. So basically, I send a httpclient request, then I tie the response stream to an event handler, so whenever there is data on the stream, the event will be raised.
Thanks for all of your inputs.
kab

What is the best way to make multiple connections at the same time?

I'm making a program that requires to make multiple connection on my website and keep it open for a few hours! So, let's say I want to make 300-500 connections and keep them up for 5 hours, if I use threads for each connection, how much CPU would it take approximately? Is there any alternative way to do this instead of using threads as it would take a lot of CPU?

Use asynchronous sockets API.
Asynchronous Server Socket Example
http://msdn.microsoft.com/en-us/library/fx6588te.aspx
Asynchronous Client Socket Example
http://msdn.microsoft.com/en-us/library/bew39x2a.aspx
Using an Asynchronous Server Socket
http://msdn.microsoft.com/en-us/library/5w7b7x5f.aspx

WCF is one option. Another is to consider using a network library which gives you the option of using either threads or asynchronous connections, NetworkComms.Net or lidgren.
Disclaimer: I'm a developer for NetworkComms.Net.

HTTP as an application message protocol doesn't keep a flow back-and-forth of messages, but only a single pair is exchanged; a request and a response, and so from an application perspective it is a connectionless protocol. The connection-oriented TCP part is only to garantuee successful delivery of all data in the request or all data in the response.
As such it doesn't make sense to talk about keeping HTTP connections open from the server. The server might do chunked encoding to pretend it can send multiple reply messages, but that won't work empirically.

Relay a request from client to Server via Proxy using sockets c#

I have custom tcp server listening on port 5888(dummy port). The proxy server listens for incoming connections. When the proxy receives a HTTP Request, it should relay the same request to a different server.
Eg:
Proxy receives: http://proxyserver.com/mypage.html
Proxy should Relay: http://MainServer.com/mypage.html
The response from the Main Server should be sent directly to the requesting client.
I have used sockets for accepting connections and parsing the raw HTTP Request before relaying the new HTTP request to the main server. This is becoming too complicated, since I have to send the Raw HTTP Request to the main server, get the response and send it to the client machine.The proxy is basically becoming a middle-man. I want the proxy only for the
one side of communication i.e to change the host address to the MainServer and then the main server should take care of sending the response to the requesting client.
How to achieve this ?

HTTP works over a TCP connection initiated from a client to a server. In presence of proxy you need at least two connections - one from client to the proxy, and one from proxy to the server. These two connections are sort of "independent" in a sense that both transmit standard HTTP requests and responses. Proxy here acts as a client to the end server.
What you want involves at least three TCP connections, and requires sending HTTP response on a different connection from the one where initiating HTTP request came on. That is outside of the HTTP proper - the client wouldn't know that it needs a second connection somewhere else, and how to match requests on one connection to responses on the other. The best you can do within HTTP is redirecting to a different server, say, with a special generated URL or something.
Just remember that HTTP response has to come on the same TCP connection as the original request.

Send and Read from a socket simultaneously

I'm working on a simple proxy server. The problem is browser sometimes re-uses the connection and sends multiple requests on the same connection.
I'm using TcpClient and Stream to make HTTP request to the server. How can I have read and write functions 'separate' from each other, like in separate threads for example. Thanks!

Its called persistent connection. If you don't want the browser to do that, you should not send this header "Connection: Keep-Alive" in your proxy response.
http://en.wikipedia.org/wiki/HTTP_persistent_connection

Can HTTP be used to track connections?

I know there is some debate as to whether HTTP is strictly connection-oriented or connectionless. AFAIK, HTTP only maintains a connection long enough to transmit the series of immediate requests. Recently, a microsoft certified architect and I were discussing a method to broadcast updates to a "connected" clients.
Imagine a game of checkers. If player1 makes a move, player2 needs to be notified. With HTTP (no TCP/UDP), the only method I am aware of is to poll. The architect disagreed with me.
So, how can you send updates to "connected" clients using solely HTTP?

There are currently 2 solutions for this:
WebSockets provide a true callback, but are not widely adopted
Use a Comet implementation (such as WebSync). This uses polling.

At the HTTP level, you can stream data that the client can pick up on, by not specifying a Content-Length or closing the connection.
Some clients/servers have a "no data" timeout though so sending a periodic keepalive is a good idea.
Replies need to be in another HTTP request though.
An extension to the stream is the client making a connection and the server not sending any data until there is something ready. The client then processes the reply and immediatly connects again for the next chunk.