To all the .NET experts, I have a question for you.
I need to do SOAP/HTTP over named pipes on Windows, in C#. (This is for a client talking to a Python library/server using SOAP for RPC. Using socket/port was deemed both insecure, and port configuration becomes a hassle.) There are two problems.
There is an HttpWebRequest class, but it only supports http URI’s. I can’t find any easy way to change it to support named pipes. Any ideas?
In theory, I could subclass WebRequest, but I don't want to have to rewrite all of the HTTP protocol in C# just to get named pipe support.
There is a PipeStream class, but it is only supported on .NET 3.5 and above. My stuff has to work with .NET 2.0….
I tried searching on google and on this site. There are very few hits (actually, no relevant ones) for HttpWebRequest in combination with named pipes (though each topic by itself has lots of hits).
Any advice is appreciated, thanks.
Have you looked at Windows Communication Foundation (WCF)? That has support for NamedPipes as a transport for SOAP requests
Related
According to my research whilst trying to solve this problem, it turns out that the .Net WebProxy class does not support Socks proxies - a tad annoying. I also can't seem to find any code or information which explains how to implement Socks 4/5 support via a class which can easily be used with HttpWebRequest (the Proxy property, to be exact).
I've found limited information via google on how I could do this. One suggestion involves changing internet explorer proxy settings - something I'd rather not do.
Does anyone know of anything which could do the job or have any suggestions? Any help would be much appreciated.
I tried numerous .Net libraries which claimed to support Socks4/5 but found many of them just did not work or would error trying to connect to proxies I knew were functioning.
I've ended up using Chilkat Software's Sock/SSL component which seems to work well for me even if I do have to manually construct the HTTP requests instead of using HttpWebRequest as I would have liked.
Update note: Chilkat.Http (similar to the HttpWebRequest class) does inherently have support for SOCKS proxies. So don't spend time trying to code your own HTTP requests as I did; just use the Chilkat.Http.SocksHostname, Chilkat.Http.SocksPort and Chilkat.Http.SocksVersion properties.
Changing IE's proxy settings won't help you at all-- the other poster was just observing that it works for IE. Because the .NET Framework doesn't support SOCKS, you'd have to write your own CERN-Proxy to SOCKS-Proxy converter, such that .NET talks to the CERN proxy (the type it supports) and your code converts that to a SOCKS proxy call.
FWIW, this is something I'm presently looking to add to FiddlerCore (www.fiddler2.com/core) because I already have almost all of the code. The only thing I really need is a SOCKSv4a proxy to test against.
Since .NET 6, socks proxies can be used natively with HttpClient. See this issue on GitHub.
Use Privoxy or same to create http proxy gateway to your socks.
Add this to main config to chain Privoxy and socks:
forward-socks5 / proxy_host:port .
And something like that to enable direct access to your local network:
forward 192.168.*.*/ .
forward 10.*.*.*/ .
forward 127.*.*.*/ .
I've never had to do IPC on Windows before. I'm developing a pair of programs, a standard GUI/CLI app, and a windows service. The app has to tell the service what to do. So, assuming the communication is local only, what would be the best communication method for these two processes?
By best I mean more robust and less error prone, not the best performance nor the easiest to code.
Note I'm asking about what to use, a standard TCP socket, named pipes, or some other means of communication only.
IPC in .Net can be achieved using:
WCF
using named pipes requires .Net 3.0 and above.
Code example
The WCF class NetNamedPipeBinding can be used for interprocess communication on the same machine. The MSDN documentaion for this class includes a code sample covering this scenario http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx
Remoting
The original IPC framework released with .Net 1.0. I believe remoting is no longer being actively developed, and you are encouraged to use WCF instead
Code example
Inter-process communication via Remoting - uses a tcp channel
Resources
GenuineChannels, sell a remoting toolkit that includes a Shared Memory Channel. http://www.genuinechannels.com/Index.aspx
Ingo Rammer, wrote the definitive .Net remoting book, Advanced .NET Remoting, Second Edition
Win32 RPC using csharptest-net RpcLibrary
I came across a project recently that has wrapped the Win32 RPC library and created a .net class library that can be used for local and remote RPC
Project home page: http://csharptest.net/projects/rpclibrary/
MSDN references:
How rpc works: http://technet.microsoft.com/en-us/library/cc738291(v=ws.10).aspx
RPC functions: http://msdn.microsoft.com/en-us/library/aa378623(v=VS.85).aspx
Also has a google protocol buffers rpc client that runs on top of the library: https://code.google.com/p/protobuf-csharp-rpc/
WM_COPYDATA
For completeness it's also possible to use the WIN32 method with the WM_COPYDATA message. I've used this method before in .Net 1.1 to create a single instance application opening multiple files from windows explorer.
Resources
MSDN - WM_COPYDATA
Code example
PInvoke.net declaration
Sockets
Using a custom protocol (harder)
For local only, we have had success using Named Pipes. Avoids the overhead of TCP, and is pretty much (at least for .NET) as efficient as you can get while also having a decent API to work with.
Since you are limited to .Net 2.0 WCF is perhaps not an option. You could use .Net remoting with shared memory as the underlying communication mechanism between app domains on the same machine. Using this approach you can easily put your processes on different machines and replace the shared memory protocol with a network protocol.
The standard method of communicating with a windows service is to use service control codes. Windows services can receive codes from 0 to 255. 0-127 is reserved for system. 128 to 255 can be used for custom commands.
If you need to send complex objects to the service use database, xml, file, tcp, http etc. Other than that for sending control commands like reload configuration, process items etc this control codes should be used.
There are additional functionalities available such as querying the service. See Windows service documentation and api.
http://arcanecode.com/2007/05/30/windows-services-in-c-sending-commands-to-your-windows-service-part-7/
Your best bet is to use WCF. You will be able to create a service host in the windows service and expose a well defined interface that the GUI application can consume. WCF will let you communicate via named pipes if you choose, or you can choose any other communication protocal like TCP, HTTP, etc. Using WCF you get great tool support and lots of available information.
I'd like to add to this discussion. Please rebuke me if this is way out there - but couldn't a semaphore (or multiple semaphores) be used for rudimentary communication?
I would like to handle HTTP on very low level - at the moment I'm stuck with HTTP CONNECT verb. It looks like HttpListener doesn't have access to these request because they are handled somewhere inside HTTP API or HTTP.SYS. I'm able to handle such requests with native TcpListener but in such case I would lose all HTTP functionality = I would implement HTTP from scratch.
I also checked FiddlerCore but it also handles these requests on some Win API layer. Is there any pure .NET HTTP stack?
Edit: I'm working on HTTP proxy with some additional request analysis and statistics so I don't want to lose HTTP parsing and in the same time I want to know about SSL connections.
Use Tcp* ans Socket*, not Http* related classes to use really low level in .NET.
TCP is at the bottom of HTTP protocol stack.
Use TCP sockets if you want it to, just use "winsock2.dll" interop calls form c#, and all related stuff like structure definitions etc, or use native C++
Well, if you are building your custom HTTP/HTTPS server or proxy and you don't mind third-party components, then our SecureBlackbox includes HTTP/HTTPS server components which let you do almost anything with any verb. Pure .NET, use any socket classes.
Ok. Again the problem is not in API but in developer :)
I have some test suite to test my implementation but the test suite was connecting directly (not as to a proxy) - that was the first problem. The second problem was that this test suite should use TcpClient instead of HttpWebRequest if I want to test Connect verb separately because HttpWebRequest uses it only internally when using proxy for HTTPS.
I hear that WCF is the new standard for communication across the network and applications in .net. The idea seems to make sense as well, provide standard interfaces for programs to communicate.
Here is my situation, I have a .net app i want to communicate to a ruby application though pipes. On the .net side (server) I would like to use WCF while the ruby side (client) will be chewing gum and duct tape.
I assume both ends don't need to be WCF but what will be involved in making this work. Is there a standard protocol WCF expects incoming requests?
Using the named pipes binding for non WCF clients could be possible, but it wouldn't be easy. You'd need to send the messages in the correct format for WCF to consume.
See this first or last entry on WCF message framing for a hint at the complexity. It's not impossible, but is it worth the effort?
Recommended is the http transport + some type of text or markup encoding, like basicHttpBinding or webHttpBinding.
Depends on your bindings, you can make your WCF a webHttp binding and make it restful (easiest) and you just do gets and posts. Other bindings you will have to use SOAP headers and such to communicate with your WCF, I have not done this myself, but im sure theres info out there on how to do it for non .net applications.
You'll want to keep your contract as simple as possible (in terms of what types you expose). Though I have not tried this myself, I know that this type of functionality is supported (.Net to Java is a common usage) and relatively easy to do.
You don't mention which side (.Net or Ruby) will be the server, but I would expect that this will be much easier to do if you host the service in WCF and consume it from ruby. Going the other way around may be a bit more of a pain because mucking with the internals of WCF can be a bit of a pain.
What sort of "pipes" are you referring to? You cannot use the named pipes bindings with any code that's not .NET.
You'll probably be better off with one of the HTTP bindings, like webHttpBinding or basicHttpBinding.
I've never had to do IPC on Windows before. I'm developing a pair of programs, a standard GUI/CLI app, and a windows service. The app has to tell the service what to do. So, assuming the communication is local only, what would be the best communication method for these two processes?
By best I mean more robust and less error prone, not the best performance nor the easiest to code.
Note I'm asking about what to use, a standard TCP socket, named pipes, or some other means of communication only.
IPC in .Net can be achieved using:
WCF
using named pipes requires .Net 3.0 and above.
Code example
The WCF class NetNamedPipeBinding can be used for interprocess communication on the same machine. The MSDN documentaion for this class includes a code sample covering this scenario http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx
Remoting
The original IPC framework released with .Net 1.0. I believe remoting is no longer being actively developed, and you are encouraged to use WCF instead
Code example
Inter-process communication via Remoting - uses a tcp channel
Resources
GenuineChannels, sell a remoting toolkit that includes a Shared Memory Channel. http://www.genuinechannels.com/Index.aspx
Ingo Rammer, wrote the definitive .Net remoting book, Advanced .NET Remoting, Second Edition
Win32 RPC using csharptest-net RpcLibrary
I came across a project recently that has wrapped the Win32 RPC library and created a .net class library that can be used for local and remote RPC
Project home page: http://csharptest.net/projects/rpclibrary/
MSDN references:
How rpc works: http://technet.microsoft.com/en-us/library/cc738291(v=ws.10).aspx
RPC functions: http://msdn.microsoft.com/en-us/library/aa378623(v=VS.85).aspx
Also has a google protocol buffers rpc client that runs on top of the library: https://code.google.com/p/protobuf-csharp-rpc/
WM_COPYDATA
For completeness it's also possible to use the WIN32 method with the WM_COPYDATA message. I've used this method before in .Net 1.1 to create a single instance application opening multiple files from windows explorer.
Resources
MSDN - WM_COPYDATA
Code example
PInvoke.net declaration
Sockets
Using a custom protocol (harder)
For local only, we have had success using Named Pipes. Avoids the overhead of TCP, and is pretty much (at least for .NET) as efficient as you can get while also having a decent API to work with.
Since you are limited to .Net 2.0 WCF is perhaps not an option. You could use .Net remoting with shared memory as the underlying communication mechanism between app domains on the same machine. Using this approach you can easily put your processes on different machines and replace the shared memory protocol with a network protocol.
The standard method of communicating with a windows service is to use service control codes. Windows services can receive codes from 0 to 255. 0-127 is reserved for system. 128 to 255 can be used for custom commands.
If you need to send complex objects to the service use database, xml, file, tcp, http etc. Other than that for sending control commands like reload configuration, process items etc this control codes should be used.
There are additional functionalities available such as querying the service. See Windows service documentation and api.
http://arcanecode.com/2007/05/30/windows-services-in-c-sending-commands-to-your-windows-service-part-7/
Your best bet is to use WCF. You will be able to create a service host in the windows service and expose a well defined interface that the GUI application can consume. WCF will let you communicate via named pipes if you choose, or you can choose any other communication protocal like TCP, HTTP, etc. Using WCF you get great tool support and lots of available information.
I'd like to add to this discussion. Please rebuke me if this is way out there - but couldn't a semaphore (or multiple semaphores) be used for rudimentary communication?