How can I communicate through an HTTP proxy with TcpClient in C#, kind of like WebProxy when using HttpWebResponse?
Well, TCP doesn't have anything directly equivalent to HTTP proxying. In HTTP, the client (generally) knows about the proxying - it talks to the proxy, and asks the proxy to connect to the real web server on its behalf.
TCP doesn't define that sort of thing, so any proxying would have to either be transparent (i.e. something that a router or the operating system does without the client knowing, e.g. with iptables) or as part of the protocol on top of TCP (HTTP proxying is a good example of this, as is SOCKS mentioned in a different answer).
If you go down to low-level socket programming, I'm pretty sure you'll need to write your own proxy client. If you're only dealing with the HTTP protocol, you're probably better off using HTTP-specific classes. If you need to do it with sockets, the HTTP spec describes the behavior of proxies reasonably well, so you could write your own client.
If you'd like to use a SOCKS proxy, there are already some SOCKS libraries written for C#. Try this one.
Related
I need to write a server that will handle a binary protocol with TLS. Nothing to do with HTTP or SOAP. But it needs to be able to accept incoming connections, with client certificates, maybe pooling, and provide responses. Ideally could also post messages back to the client asynchronously but not a requirement.
Can this be done with a special IIS plug in? or with WCF? Or is it best done by just listening on a raw socket?
Edit. To be clear, this is a binary protocol that is well defined by an industry standard. I do not want any software to interpret it, package things into objects etc. I just want to have a listener send bytes sent by a client to a class and then send them back.
I think Remoting can help you, you can make your own channel for example
I want all web traffic (HTTP, HTTPS and DNS - Are there any others?) goes through a local application and goes to a server application and from there goes to internet. How can I do this?
I have wrote an Async TCP server and I know socket Async programming in C# using SocketAsyncEventArgs (I am not a master with just one project but I think I can understand some basics).
The only way to do this is to write a Windows network driver - you cannot do this from userland. This is how VPNs work.
There are userland tunnels you can develop that tunnel a single connection, but they require the user to configure their applications to use it first, so you cannot unilaterally redirect all network activity.
From your question, I'm guessing you're not too familiar with Winsock internals or writing kernel network drivers, so for now I'm going to say I think this is a take above your level of competence right now.
However if you'll settle for a bit of an impure approach, you can implement a SOCKS proxy easily enough, but this requires configuring browsers to use your proxy server - at least this way you'll tunnel HTTP and HTTPS, however I'm uncertain about whether or not browsers use SOCKS servers for DNS or if they use the OS-provided DNS functionality.
Like #Dai suggested, use a SOCKS proxy. It operates above the transport layer, therefore a SOCKS server can be configured to serve any application protocol operating on typical TCP/UDP.
This is exactly what TOR does to mask all traffic, not just HTTP.
Did Wcf replace socket?
for client server application i need that client send some messages to server and the server can do the same thing without waiting request from any client.
So can i do this or wcf can only expose many services that client need and the communication can't be interactif and bidirectionnal?
thanks
Do you want the connection to be persistant? If so then this doesn't sound like a good case for WCF. Perhaps take a look at something like ZeroMQ instead.
Wcf will never replace the sockets. The WCF just implements some concrete protocols over the TCP so if you need something else like IP or even UDP you still need to use the sockets.
If you need a stable TCP connection you still need a socket. Also this discussion could be helpful for you.
http://forums.silverlight.net/t/17502.aspx/2/10
All I want to do is forward every request coming into my server and port, to the same server and a different port, and optionally add one header.
That is it. is there a really simple C# program I could write, that just takes bytes from here and pushes them to this other port, and same with the response, just throws it down to the client?
sTCPPipe by Luigi Auriemma is a great simple C++ TCP pipe implementation that does exactly what you need, but does not allow the addition of extra headers.
For a C# implementation that does HTTP header inspection and acts as a proxy and not just a simple tunnel, look at the Mentalis proxy project. You can easily modify it to direct all requests to one address instead of the address specified in the HTTP Host Header, but the source is delegate spaghetti.
Or you can write one yourself with a TcpListener that listens on say, port 8080, and after accepting a connection connects to another host (using a different socket) and relays all traffic between the two. If you don't use non-blocking sockets, you'll need to use a few threads to accomplish this.
If it's for commercial use, then the challenge with writing a proxy is to make sure it is reliable and can withstand all types of buffer overflow attacks.
What do I use for two way communication over the internet without the necessity to open ports on the client side?
Users won't agree to open ports and do port forwarding on the client side although everything is possible on the server side.
But,I need to accomplish two way communication..
How do I go about achieving this?
It doesn't matter whether its WCF or remoting or webservices...
I just need a quick and fast way to just get the concept to work out and distribute the application.
ofcourse,it's going to be through the internet.
Please help..
Thanks
Edit : Please note that i need to connect multiple clients and maintain a session for each client.
WCF supports duplex HTTP bindings.
As long as the initiating client can access the service, a callback contract can be defined to call the client. It simply keeps the HTTP connection once the client has initiated it.
It depends what you want to do. Duplex WCF can work, but through NAT and Proxies it becomes somewhat "iffy" because it depends on the client opening a WCF endpoint and maintaining the connection.
I wrote a beginners guide to WCF callbacks a while ago - it's simple enough to do, but you'll need to test it a lot, from various client setups.
Connect via TCP (raw sockets, or higher implementation) to a your central server.
Your server should have an application that listens to a specific, well known, TCP port.
Each client connects to your server, using the specific port, and "logs in".
Write an application protocol above the TCP (authentication, session management, etc.), and there you have it, since a TCP connection, once established, works for both directions.