Simplest way to communicate between Python and C# using IPC? - c#

I have some C# code that needs to call a Python script several thousand times, each time passing a string, and then expecting a float back. The python script can be run using ANY version of Python, so I cannot use Iron python. It's been recommended that I use IPC named pipes. I have no experience with this, and am having trouble figuring out how to do this between C# and Python. Is this a simple process, or am I looking at a decent amount of work? Is this the best way to solve my problem?

Use zeromq.
allows very light messaging without a need for broker
is available for many platforms
can communicate over TCP socket, unix socket or inside a process
Here is my answer using zeromq https://stackoverflow.com/a/23227631/346478
It serves for messaging between different Python programs, but exactly the same method of communication can be used between other platforms. Just keep the messages passed around interopable - both sides must understand the content properly. You can play with binary data, but very often json representation work quick and easy too. But there are many serialization frameworks like result buffers and others, which might help you to encode result.

Based on the what you have said, you can connect to the python process and catch standard output text. Easy, fast and reliable!

Related

What is the fastest way to have C# communicate with Python?

I need a way for c# to communicate with an arbitrary version of Python. The user passes in a path to Python, so they can choose any version they want. I need to be able to pass a string to Python, and get back a float. This needs to happen several thousand times. Right now i'm just using standard in/out, but it seems to be very slow. Is there any faster way to do this?
Typically, the "best" way to handle this type of scenario is to use IronPython instead of having the user supply their own Python runtime.
You can also use Python for .NET, but this again will tie you to a specific version of Python.
If you control what's called in Python, but need arbitrary versions of python, you may be able to use a common messaging service. One option would be to setup an IPC channel via pipes, which are supported in Python and .NET. This would provide fast C#->Python->C# communication while keeping the process separate.
If you need arbitrary versions and installations of python, than executing and fetching information via the shell process may be the only option.
Very fast is using zmq, libraries are available for both, C# and Python, can talk across network, in some situations is faster then plain TCP.
E.g. iPyhton is using it for internal inter-component communication.
My StackOverflow answer shows Lock server implemented over zmq which could be used to serve C# too.

Communication between a C# and Python application hosted on the same machine

We're working on a project that requires us to interface with a specific set of hardware; one set can be controlled very easily using C#, the other of which is natively programmed using Python. Part of the project involves getting the hardware running on Python to communicate with the hardware running through C#, and unfortunately, due to time constraints, we aren't able to create a set of C# or Python software to control the other set of hardware.
The set of hardware running on Python is completely event based, in that we can program functions that are called when certain conditions are met by the hardware. Our thought was to modify the C# application controlling the other set of hardware to host the Python application (using something like Application.Run()), then program the Python functions to propagate relevant data to the C# application as the events come in from the hardware.
We're considering using a socket connection to handle communication between the two, as both C# and Python are fairly simple to get working that way (or so our Python guy claims). The biggest concern with this that we have is if there will be any issues with the fact that both programs will be hosted on the same machine. If this won't be an issue, we would probably end up using a shared library such as 0MQ
We've also done some research into the following areas:
Pipes / Named Pipes
Message Queues
Shared Memory
Basically we want to know which method of these (or any others) will be the easiest to implement with these languages, and which will give us the best performance. We are concerned only with speed and accuracy of the data (ie, if using network packets, one that will drop the least). Security is not a concern.
Ideally, there should be one data stream going from the Python application to the C# application, and two data streams going from the the C# application to the Python application. The host machine will be running Windows 7. I can give additional information as needed.
One option is to try IronPython. Since IronPython is a .NET language, communicating with C# code should be easy.
It seems worth looking into how hard it would be to get your existing Python code running on IronPython.

java server <-> c# + javascript + java + * clients

What "technology" would you suggest to exchange some kind of messages between a Java server and several clients written in C#, Javascript and Java?
The background story:
In our current project we're trying to build a generic UI backend in Java (running on the server) which is then "bridged" into several UI frontends by means of different UI adaptors (running on the client, the server, or both). While our server technology will always be Java, there will be C# (Silverlight), JavaScript and Java clients. Maybe even more in the future (different Smartphones, Tablets).
The UI backend and UI frontends communicate through a bunch of more or less simple messages (mostly name/value-pairs) each of which encapsulates a specific property/state/data change on the client or server respectively. Within a single request cycle, several such simple messages are aggregated into one big message which is then passed from backend to frontend or vice versa. At the moment sending and receiving messages is done at a single entry point on the client as well as on the server. So there are no server methods exposed as WebService etc. - simply because this would most definitely be to slow in our case.
Our current prototype consists solely of a Java server, a Java Desktop Client (Swing) and a Java Web Client (Vaadin). The message exchanged between backend and frontend is effectively a list of POJOs (each representing a specific "change") serialized/deserialized to/from XML. So far, so good.
Now C# and Javascript come to the table. Since we want to work with some kind of object in each technology, we thought it would be a good idea to specify the messages/changes/pojos in some kind of abstract language and then generate objects for each target language. At some point these objects could then be serialized/deserialized and sent over the wire (probably via http/s). For this purpose we thought of Google's protocol buffers or Thrift. What do you think?
For the moment our synchronous request-response-cycle is enough but we will need asynchronous request-response or server-push respectively pretty soon. That's why we thought of using something like ActiveMQ straight away. What do you think? Too much? If not, how can we accomplish the object generation mentioned above (xsd, jaxb, ? for js)? Are there better ways? I've never used ActiveMQ but according to the website it should be possible with Java, C# (Spring.NET) and somehow with Javascript (STOMP) too. However, this seems pretty complex to me...
Any tips, hints, experiences or comments about this or related topics would be really helpful.
Thank you in advance.
I would recommend using webservices. The WSDL language defines objects and messages of your protocol in abstract form. Most modern languages like Java and C# have tools for converting WSDL to native types and libraries for handling I/O.
For the last two years i have been involved in building a similar system: backend for our project is c#, java and bunch of other languages, frontend is phone clients for ios, android, symbian, all the common webbrowsers and even windows desktop apps.
For all these services we use JSON, since it seems to be most widely supported format across all languages and platforms, it decodes fairly fast on the clients compared to xml based solution (esp. webbrowsers/javascript) and it has a pretty low overhead that compresses extremely well which is great for clients that lack bandwidth.

Network programming and Packets interactions

Greeting,
This month I will start working on my master thesis. My thesis's subject is about network security.
I need to deal with network interfaces and packets.
I've used shappcap before to interact with packets but I'm not sure if C# is the most powerful language to deal with network programing and packets.
I worked a bit with wireshark and I saw how powerful it is and as you know winsharp is open source developed using C++.
I'm not sure if I should use C# or C++ for network security programming and I want your through about the best language might be for network programming and packets interaction.
should I use C#, C++, or java or some thing else?
please give me your advice.
Thank you,
UPDATE
..........................
I'm going to do different packet mining by taking each packet and read each field on it then use these values and in same stages I would modify some of the packets value then resend them back.
I want to control the packet since it received by the network interface until it passes to the application layer.
also
You'd be able to do network programming using almost any language you want to. If you are equally comfortable in all of the languages you've mentioned, you should determine what system libraries or APIs will you be interfacing with. For example, if you will be doing packet-level network programming on a Unix system, C would probably be your best best. If you want to integrate with Wireshark, go with C++. If you want to use an Apache Commons component, use Java. I suggest you come up with a more specific set of requirements for your actual program before trying to decide which language to use.
WireShark uses WinPCap so you could go that route as well.
For security application, is that a intrution detection system or do you actually want to drop offending packets? WinPCap, SharpPCap etc. do not allow you you drop packets, for this you will need to look at some kind of intermediate driver or look at Windows Filtering Platform (WFP)
http://www.microsoft.com/whdc/device/network/WFP.mspx
IMHO, if you can find a callback driver that calls back to user mode and allows you to filter the packets from C# or C++, this would probably be fine for experimental purposes etc. but for a production solution, I think you would need to stick to the kernel level to ensure that you can keep-up with the peek volume.
Use C++, Boost and Poco and you can do what you want. Boost asio is: Portable networking, including sockets, timers, hostname resolution and socket iostreams. Poco library also provides solutions for network, cryprography NetSSL ... and more. For more information you can visit www.boost.org and www.pocoproject.org
You can use java if you like - jpcap works well.
I would suggest using C#, since there is a very strong library called Pcap.Net that wraps WinPcap with .NET code. This should make it easy for you to receive, send and interpret packets different packets of different protocols.

What is the best way for C# app to communicate unix c++ app

the ways I can think of
Web service or soap
Socket
Database table
shared file
Any concise example you know of for webservice?
Web services or soap would be fairly easy, however, if the C++ application isn't a web server naturally (or the C# application), it may be easier to just use socket programming directly.
Sockets are fairly easy to use from both C# and C++. They give you complete control over the type of date transmitted, at the cost of potentially a little more work in the handling.
The biggest issues to watch for are probably endianness of binary data, and encoding of text data, if you use sockets directly. Otherwise, it's very easy.
Since you are already aware of the Web service and socket approach, I'll mention some other options. If you like simplicity, check out XML-RPC. This is what SOAP was before large standards committees and corporate interests began to control the specification. You can find implementations of XML-RPC for just about every major programming language out there. Hessian is an interesting binary protocol that has many fans and supports just about every major language as well. Protocol Buffers is popular within Google. The official version from Google does not support C#. However, the two highest rep users of SO do provide ports of protobuf for the .Net space.
I will probably be ridiculed for this, but also take a look at CORBA. It's not in vogue these days, but has many substantial technical creds, especially if one end of the communication is C++. IMHO, it's WS-* with OO support and no angle brackets required. For interop, I think it still should have a seat at the table. When engaged in C++ development, I found OmniOrb to be quite effective and efficient. Take a look at this SO Question for some pointers concerning using CORBA in .Net.
Sockets are easiest; and I would always go for that first. If database is an option, that's also trivial, but that would really depend. If it's queued events, that would make sense, but if it's request/response, it's probably not so great.
you can use gsoap to have a C/C++ program use a webservice.
You can also call a cgi program that is written in C++.
I have written a server in C that communicated with a C# client, and the endianess can be a pain to deal with, webservices is so much simpler.
Do you want it to communicate with each other (for instance, through tcp (like many others have pointed)) or do you want to be able to translate objects from C# to C++? If so, check out Apache Thrift (http://incubator.apache.org/thrift/).

Categories

Resources