Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.unix.programmer > #626 > unrolled thread

Linux to windows IPC

Back to article view | Back to comp.unix.programmer

Contents

  Linux to windows  IPC Matt Charles <mcharles48@gmail.com> - 2011-05-20 08:21 +0100
    Re: Linux to windows  IPC Mark <i@dontgetlotsofspamanymore.invalid> - 2011-05-20 10:38 +0100
    Re: Linux to windows  IPC Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-20 15:00 +0100
    Re: Linux to windows  IPC William Ahern <william@wilbur.25thandClement.com> - 2011-05-20 13:19 -0700
      Re: Linux to windows  IPC Matt Charles <mcharles48@gmail.com> - 2011-05-21 09:25 +0100
        Re: Linux to windows  IPC Ian Collins <ian-news@hotmail.com> - 2011-05-21 20:34 +1200
        Re: Linux to windows  IPC Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-22 21:26 +0100
        Re: Linux to windows  IPC Matt Charles <mcharles48@gmail.com> - 2011-05-23 12:19 +0100
    Re: Linux to windows  IPC john.spooner@gmail.com - 2012-10-25 06:31 -0700

#626 — Linux to windows IPC

Hi,

I have a Windows .NET client process that I'm developing that's going to 
need to communicate with some C code running on a Red Hat linux box. 
The client will send a text request and receive a text response after 
some database processing has been carried out, the calls will need to be 
synchronous.

What options do I have?  I can think of a few:

Raw Sockets
CGI in a webserver
SOAP / REST calls
Some sort of RPC generator / library?
what others?


What works well and has good library support to save me reinventing the 
wheel?

Cheers,

Matt

[toc] | [next] | [standalone]

#628

On Fri, 20 May 2011 08:21:52 +0100, Matt Charles
<mcharles48@gmail.com> wrote:

>Hi,
>
>I have a Windows .NET client process that I'm developing that's going to 
>need to communicate with some C code running on a Red Hat linux box. 
>The client will send a text request and receive a text response after 
>some database processing has been carried out, the calls will need to be 
>synchronous.
>
>What options do I have?  I can think of a few:
>
>Raw Sockets
>CGI in a webserver
>SOAP / REST calls
>Some sort of RPC generator / library?
>what others?
>
>What works well and has good library support to save me reinventing the 
>wheel?

There are probably 1000s of ways of doing this and I'm not going to
name them all ;-)

A lot depends on who is going to maintain this software and what
technology they are happy with.  There's no "best" way IMHO.

If the communication protocol is very simple then I would use TCP/IP
sockets, but then I have already developed loads of similar code.

Failing that you could use SOAP since there are a large number of SOAP
frameworks available. 

-- 
(\__/)  M.
(='.'=) Due to the amount of spam posted via googlegroups and
(")_(") their inaction to the problem. I am blocking some articles
posted from there.  If you wish your postings to be seen by
everyone you will need use a different method of posting.

[toc] | [prev] | [next] | [standalone]

#630

Matt Charles <mcharles48@gmail.com> writes:

[...]

> What options do I have?  I can think of a few:
>
> Raw Sockets
> CGI in a webserver
> SOAP / REST calls
> Some sort of RPC generator / library?
> what others?
>
>
> What works well and has good library support to save me reinventing
> the wheel?

Rest assured that the probability that anything you can ever come up
during your whole lifetime (or that anything someone came up during
the about sixty years stored program computers have existed) while
remain in use for a few thousand years without a basic design change
is low enough to be considered equivalent to zero for all practical
purposes.

[toc] | [prev] | [next] | [standalone]

#632

Matt Charles <mcharles48@gmail.com> wrote:
> Hi,

> I have a Windows .NET client process that I'm developing that's going to 
> need to communicate with some C code running on a Red Hat linux box. 
> The client will send a text request and receive a text response after 
> some database processing has been carried out, the calls will need to be 
> synchronous.

Synchronous where? Regarding the .NET client or the C "code" on the server?
Synchronous how? Are you talking basic I/O or sychronous in regards to some
overall transactional flow?

Windows and .NET frameworks tend to dictate the use of threads for
concurrency (even "asynchronous" calls are just put onto another thread).
This means that all the different modes of communications are more alike
than not, in terms of low-level I/O implementation details.

Not so in C. In C it's as just common to use threads as non-blocking I/O.
There may be callbacks or the implementation may use a resumable state
machine which falls back to the caller. And mixing and matching methods is
more of a hassle than in .NET, where if a library uses a callback or
delegate you can just block and synchronize on a semaphore triggered by the
callback, or otherwise coax the behavior of the library to suit the
application's overall design.

Point being, what will dictate your choice of methods is probably what is
most convenient for the C, server-side of this equation. Is the server code
using its own event loop, something like libevent, or is it just
multithreaded? Are there ready-made solutions that are easily pluggable into
the overall design of the C code?

> What options do I have?  I can think of a few:

> Raw Sockets
> CGI in a webserver
> SOAP / REST calls
> Some sort of RPC generator / library?
> what others?

> What works well and has good library support to save me reinventing the 
> wheel?

Good library support for the C code? Again, it all depends. freshmeat.net is
a solid place to start looking for a solution.

[toc] | [prev] | [next] | [standalone]

#634

Thanks for the input so far, but I'll try and explain more clearly.  :-)

I have an existing Red Hat Linux C function  (complex business logic 
that contains some database access),  it takes some strings as input 
parameters and returns a string result.    This function is currently in 
a batch program and works fine.

However I now also want to call this function somehow from a new Windows 
.NET GUI application.  The user will press a button, get an hour glass 
and wait for the response to come back  (this is what I mean by 
synchronous).     However there may be multiple users on different PC 
pressing the button at the same time, so the solution will have to cope 
with that.

So I'm going to need to repackage my C code in some way to make this happen.

One possible solution: Package the batch program up as a CGI executable 
and call it from Apache.   The .NET code will build a URL with 
parameters and submit it to the apache webserver. The server runs the 
CGI program, which extracts the parameters from the QUERY_STRING 
environment variable that Apache creates and then calls the C function 
and outputs the result as HTML to stdout.  The .NET client can then 
interpret this to get the result.     I'm sure this will work but the 
approach seems a little "dated".

Are there any "better" solutions that anybody can think of.

[toc] | [prev] | [next] | [standalone]

#635

On 05/21/11 08:25 PM, Matt Charles wrote:
> Thanks for the input so far, but I'll try and explain more clearly.  :-)
>
> I have an existing Red Hat Linux C function  (complex business logic
> that contains some database access),  it takes some strings as input
> parameters and returns a string result.    This function is currently in
> a batch program and works fine.
>
> However I now also want to call this function somehow from a new Windows
> ..NET GUI application.  The user will press a button, get an hour glass
> and wait for the response to come back  (this is what I mean by
> synchronous).     However there may be multiple users on different PC
> pressing the button at the same time, so the solution will have to cope
> with that.
>
> So I'm going to need to repackage my C code in some way to make this happen.
>
> One possible solution: Package the batch program up as a CGI executable
> and call it from Apache.   The .NET code will build a URL with
> parameters and submit it to the apache webserver. The server runs the
> CGI program, which extracts the parameters from the QUERY_STRING
> environment variable that Apache creates and then calls the C function
> and outputs the result as HTML to stdout.  The .NET client can then
> interpret this to get the result.     I'm sure this will work but the
> approach seems a little "dated".

So is the wheel, but we still use them.

Most "web service" layers (including windows beloved SOAP) are just 
fancy wrappers around what you describe.  Sure you could be more 
"modern" and use SOAP, but why bother?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#640

Matt Charles <mcharles48@gmail.com> writes:
> I have an existing Red Hat Linux C function  (complex business logic
> that contains some database access),  it takes some strings as input
> parameters and returns a string result.    This function is currently
> in a batch program and works fine.
>
> However I now also want to call this function somehow from a new
> Windows .NET GUI application.  The user will press a button, get an
> hour glass and wait for the response to come back  (this is what I
> mean by synchronous).     However there may be multiple users on
> different PC pressing the button at the same time, so the solution
> will have to cope with that.
>
> So I'm going to need to repackage my C code in some way to make this happen.
>
> One possible solution: Package the batch program up as a CGI
> executable and call it from Apache.

[...]

> I'm sure this will work but the approach seems a little "dated".
>
> Are there any "better" solutions that anybody can think of.

Provided you don't need authentication, a much simpler and even more
'dated' alternative exists: Create something which reads the input
parameters from its standard input and writes the result to its
standard output and make this accessible on some TCP port via inetd.

[toc] | [prev] | [next] | [standalone]

#644

>
> One possible solution: Package the batch program up as a CGI executable
> and call it from Apache. The .NET code will build a URL with parameters
> and submit it to the apache webserver. The server runs the CGI program,
> which extracts the parameters from the QUERY_STRING environment variable
> that Apache creates and then calls the C function and outputs the result
> as HTML to stdout. The .NET client can then interpret this to get the
> result. I'm sure this will work but the approach seems a little "dated".

>


I just tried my simple CGI approach.  The .NET client code is very easy:

Dim webClient As System.Net.WebClient = New System.Net.WebClient()
Dim result As String = 
webClient.DownloadString("http://hostname.com/webservices/mc/dbtest.cgi?param1=test")


This request takes 0.12 seconds and that includes the network traffic 
time,  connecting to the database, performing a query and returning the 
results.

So I'm very happy with that.  Most of the time is taken up with creating 
the database connection,   I might look into using FastCGI  and 
maintaining a persistent database connection to make things even more 
efficient.

[toc] | [prev] | [next] | [standalone]

#3646

On Friday, May 20, 2011 12:21:52 AM UTC-7, Matt Charles wrote:
> Hi,
> 
> I have a Windows .NET client process that I'm developing that's going to 
> need to communicate with some C code running on a Red Hat linux box. 
> The client will send a text request and receive a text response after 
> some database processing has been carried out, the calls will need to be 
> synchronous.
> 
> What options do I have?  I can think of a few:
> 
> Raw Sockets
> CGI in a webserver
> SOAP / REST calls
> Some sort of RPC generator / library?
> what others?
> 
> 
> What works well and has good library support to save me reinventing the 
> wheel?
> 
> Cheers,
> 
> Matt

no one mentioned xmlrpc.  I kind of like it.  it implies an http server, roll your won or apache so its much like cgi.  But there is a standard discovery protocol and schema for function names and arguments.  Not very fast however.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.unix.programmer

csiph-web