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.
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
The project is to build a messaging mechanism between a Python and C# program via ZeroMQ .
I want messages to be able to travel in/out from both ends at any time, which is NOT a basic request-reply model a.k.a. REQ/REP.
One way I can think of is to build a PUB/SUB model on two ports, i.e. two one way channels.
Is there any method to get a real duplex channel?
There are several ways to do this with ZeroMQ. I suggest using a DEALER/ROUTER socket pair:
Choose one program to be the "server", the other the "client".
The server will bind a ROUTER socket on a port.
The client will connect a DEALER socket to the server's ROUTER port.
(Note: this implies that the client must know the server's IP and port in advance.)
At this point the client can send messages to the server, but the server has no way to send to the client.
The client sends a "HELLO" message to the server.
The server will receive a message that includes the client's address and the HELLO message. Now the server can send messages to the client using the client's address.
DEALER/ROUTER is considered an "advanced" socket pair in ZeroMQ. My description here is very high level. You'll really need to read the docs to get the most out of ZeroMQ.
Oh yes, Sir!
Use the PAIR-PAIR or even the XREQ-XREP ought make it.
The best next step is to carefully read the respective Scalable Formal Communication Pattern archetypes' access-points' API documentation, so as to cross-check, that all pieces of pre-wired behavioural logic meet your Project needs and voilá, harness them in your messaging setup and tune-up the settings so as to meet you performance and latency needs.
That is this simple ( thanks to all the genuine knowhow hidden in these builtins ).
Using for years this very sort of inter-platforms integration among Python + C/MQL4 and other computing nodes, so well worth one's time to learn the powers and strengths of ZeroMQ.
How do I develop an application that modifies all requests to server, listens to local ports, adds headers, and then transfers between client and server?
Grab a copy of mentalis: http://www.mentalis.org/soft/projects/proxy/
It supports SOCKS4/5 as well as HTTP proxy. You can take a look at the source and figure it out - its not that hard.
[EDIT - and if you're specifically looking at implementing SOCKS, you should read the protocol definition: http://www.openssh.org/txt/socks4.protocol. Theres really only one message you need to implement in a basic proxy (CONNECT) and all you do is parse the target IP/port, open a socket and start relaying data to the incoming socket that sent the request.]
After sending some tcp data with the blocking/non-blocking methods such as:
Socket.Send() or Socket.SendAsync()
How can I know that my data has received an ACK message?
Can .NET know if TCP data has been successfully sent?
The only way to know for sure is to implement some kind of application-level acknowledgement. The TCP level "ACK" packet is not exposed to the application level at all, so you have to use something more than that.
You make the other end respond to it.
Even if TCP has Acked it, if the receiving end terminates (for good or bad reasons) before processing the message and acting on it, you still don't know, so the only way to know is for the other end to tell you.
This information isn't available from .net's class libraries. I had the same kind of considerations when I started working on this port scanner in C#. I have made use of a .NET wrapper for libpcap (after installing the corresponding driver), the SharpPcap (http://sourceforge.net/projects/sharppcap/), in order to get this kind of information. The ACK packets are obtained through SharpPcap's interface (invoking the native libpcap interface's transparently).
My application is NScanner Port Scanner/Sweeper and you can find the code at codeplex, referencing to you my simple usage of the aforementioned library (http://nscanner.codeplex.com/).
I hope I helped.
"I'm trying to focus on how can you know when your data has been accepted by the other-side of the connection."
I think you need to be aware what type of application layer protocol you are going to implement and what impact this has on application performance.
Take HTTP as an example of a "Streaming like" protocol. A server posts a stream of data to a client. There are no more additional application layer "ACKs" and the server doesn't actually care when and how exactly his stream of data arrives. This is very efficent on high latency links.
Now compare this to SMB! Instead of streaming a file, data is partitioned into blocks. Every successfully transferred block of data is acked on the application layer. This gives you more control, however, it effectively kills the protocol on WAN networks (check out "Bandwidth Delay Product").
Taking this into consideration, you can come up with your own design for your custom protocol.
The TCP layer will keep resending the packet until it receives a successful ACK.
Send will block until this happens - SendAsync will not block, and you can continue processing other stuff while the TCP layer handles sending the packet.
I recommend using Pcap.Net.
You can easily sniff packets using this library in C# and then easily check the packet values.
You can also easily build and send packets.
If you are really certain that you need to know the packet level details of your TCP connection, then in addition to creating the TCP socket for sending, you need your application to use the winpcap API to look at the raw traffic as well. You can install a filter to only receive packets relevant to the particular IP,port combination that determines your remote side.
There are a couple of projects out there creating .NET wrappers for libpcap, for example here
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.