Simulate socket with files or stdin/stdout

[Jean-Pierre Bergamin]

Dear python-Community

We are forced to use a quite old simulation software that's based on
Modula-2. The idea is now to let this software "talk" to the outside world
over a TCP/IP network.

Since the program has no possibility to use sockets or other mechanisms to
send data over the network we have the idea to let python do the network
part and let the simu software communicate with the python script in some
other way:

One idea is to use stdout and stdin (but I'm not even sure if stdout/in are
available in the simulation software).

+------------+ stdout stdin +------------+ socket.write
| |------------------->| python- |----------------
| Simulation | | script |
| |<-------------------| |<---------------
+------------+ stdin stdout +------------+ socket.read
The other idea is to use files to communicate between the simultion program
and the python script.

+------------+ +------+ +------------+ socket.write
| |---->| |---->| python- |--------------
| Simulation | | File | | script |
| |<----| |<----| |<-------------
+------------+ +------+ +------------+ socket.read
Now my question is, if someone has done something similar and can give me
some hints where to start, what to look for etc. Maybe someone even has
another idea how to solve this problem.

A skript that does something similar like "netcat" would be a good starting
point, since I'm really new to python programming.
The script should be usable on the MAC, PC and UNIX platform.
I'm very thankful for any input you can give me to find a good solution for
this.
Thanks

James

[Josiah Carlson]

[

Now my question is, if someone has done something similar and can give me
some hints where to start, what to look for etc. Maybe someone even has
another idea how to solve this problem.

A skript that does something similar like "netcat" would be a good starting
point, since I'm really new to python programming.

The script should be usable on the MAC, PC and UNIX platform.

On OSX and *nix, you'll have no problems using stdin and stdout for
communication with Python (I don't know about Modula2). In Windows,
you're going to have a few issues with stdin and stdout, but there are
workarounds using pywin32.

On OSX and *nix, you'll have no problems using files for communicating
with Python. In Windows, files can't be used as pipes like they are in
*nix, so this isn't even an option.

I'd say try for stdin/stdout, and check out the documentation on doing
stdin and stdout with pywin32.

- Josiah

[Donn Cave]

In article <c4**********@newshispeed.ch>,
"Jean-Pierre Bergamin" <ja***@ractive.ch> wrote:

We are forced to use a quite old simulation software that's based on
Modula-2. The idea is now to let this software "talk" to the outside world
over a TCP/IP network.

Since the program has no possibility to use sockets or other mechanisms to
send data over the network we have the idea to let python do the network
part and let the simu software communicate with the python script in some
other way:

One idea is to use stdout and stdin (but I'm not even sure if stdout/in are
available in the simulation software).

+------------+ stdout stdin +------------+ socket.write
| |------------------->| python- |----------------
| Simulation | | script |
| |<-------------------| |<---------------
+------------+ stdin stdout +------------+ socket.read

On UNIX (and MacOS X), it may be easier than this already.
If your application will support the above configuration,
then it will almost for sure talk directly to the socket.
Try this:

import posix
import socket

def bind(port):
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(('', port))
s.listen(1)
c, a = s.accept()
print 'connection from', a
s.close()
return c

s = bind(2004)
fd = s.fileno()
posix.dup2(fd, 0)
posix.dup2(fd, 1)
posix.close(fd)
posix.execve('/usr/local/bin/similator', ['similator', '-flag1'],
posix.environ)
I've used posix.this and posix.that, instead of the politically
correct os.this and os.that, to emphasize the fact that this
is not portable to Windows.

If the above works, you'll be able to telnet directly to the
application host, port 2004, and interact with the application.
This obviously needs to be made a little more secure, but as
long as it's just authentication and authorization, that can
happen prior to the execve().

Donn Cave, do**@u.washington.edu

[Cameron Laird]

In article <do************************@nntp4.u.washington.edu >,
Donn Cave <do**@u.washington.edu> wrote:

In article <c4**********@newshispeed.ch>,
"Jean-Pierre Bergamin" <ja***@ractive.ch> wrote:

We are forced to use a quite old simulation software that's based on
Modula-2. The idea is now to let this software "talk" to the outside world
over a TCP/IP network.

Since the program has no possibility to use sockets or other mechanisms to
send data over the network we have the idea to let python do the network
part and let the simu software communicate with the python script in some
other way:

One idea is to use stdout and stdin (but I'm not even sure if stdout/in are
available in the simulation software).

[Donn Cave]

Quoth cl****@lairds.com (Cameron Laird):
[... re invoking application with connected socket for unit 0 & 1 ...]
| I wonder how close the effect will be to recreation of inetd
| <URL: http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?inetd >.

Pretty close, given the root privilege to configure inetd and
no intent to add any authorization checks, logging or other
embellishments.

Donn Cave, do**@drizzle.com

[William Park]

Jean-Pierre Bergamin <ja***@ractive.ch> wrote:

Dear python-Community

We are forced to use a quite old simulation software that's based on
Modula-2. The idea is now to let this software "talk" to the outside world
over a TCP/IP network.

Since the program has no possibility to use sockets or other mechanisms to
send data over the network we have the idea to let python do the network
part and let the simu software communicate with the python script in some
other way:

One idea is to use stdout and stdin (but I'm not even sure if stdout/in are
available in the simulation software).
This might be important, so you should find out... don't you think?

+------------+ stdout stdin +------------+ socket.write
| |------------------->| python- |----------------
| Simulation | | script |
| |<-------------------| |<---------------
+------------+ stdin stdout +------------+ socket.read
In Bash, Ksh,
exec 3<>/dev/tcp/remote.host/4000 0<&3 1>&3
simulation
exec 3<&-
You can achieve the same thing, by running 'simulation' under 'inetd'.


The other idea is to use files to communicate between the simultion program
and the python script.

+------------+ +------+ +------------+ socket.write
| |---->| |---->| python- |--------------
| Simulation | | File | | script |
| |<----| |<----| |<-------------
+------------+ +------+ +------------+ socket.read

Bad design. Outgoing data from 'file' can go to 'simulation' or to
'python-script'. How do you know what data should go to what direction?
That is, how does 'file' know whether 'simulation' or 'python-script' is
reading it?

If "input" and "output" files are different, then it's different story.

--
William Park, Open Geometry Consulting, <op**********@yahoo.ca>
Linux solution for data processing and document management.