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

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.

Related

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

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!

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.

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/).

Mono - sharing code on client and server . .

We are trying to come up with our client and server standard and there is a big debate. One school of thought is C# client and java servers using some type of proprietary messsage library to share data objects (think XML like structure . .)
The issue with this model is that there is lots of code that needs to be duplicated (validation, parsing) that could simply be reused if you went with C# on the server as well. If there is a big push to use linux machine then wouldn't mono support your goal . .
anyone else have this dilemma?
There are frameworks for this. ICE (ZeroC), "protocol buffers", etc.
For example, my protocol buffers implementation (protobuf-net) works on mono, MS .NET, CF, Silverlight etc - and the binary format is compatible with a range of languages (java, etc). If you start from a .proto (a bespoke definition language), you can use it to generate the object layer in each language you need.
In any case I would use Protocol Buffers or something else defined in a language neutral form for the comms, to ensure that you aren't restricted in future.
Once you've done that you can start with C# on Mono. And then if that proves to be unworkable, you can switch to a different language.
I would suggest you use some old-but-good standard for transferring data between the two, SOAP and XML-RPC come to mind as examples for this. If either of these is possible or feasible, you may want to try JSON or writing your own XML format. Protocol buffers has been mentioned around lately quite a lot but I haven't looked into it so I really can't say anything about it.
I would try to keep the client and the server the same runtime (Java or CLR). We have had plenty of success using a mix of Mono and .Net client/Server.

Categories

Resources