SocketServer: replace network by hard drive

[antoine]

Hello,

I would like to create a python server for which the requests are
passed by files on the hard drive instead of a network.
I am currently looking at the SocketServer python module, hoping for
an easy modification.

Is it doable at all?
If yes, how should it be done?

Thanks,
Antoine.

 

[Dennis Lee Bieber]

I would like to create a python server for which the requests are
passed by files on the hard drive instead of a network.
I am currently looking at the SocketServer python module, hoping for
an easy modification.

Is it doable at all?
If yes, how should it be done?

Uhm... First question: how will the server know a client is
"connecting"? Are you monitoring some known directory for the appearance
of a new file (created, in theory, by the client)...

And what will are "request" consist of -- an identifier for the
client process (including perhaps the name of a file to be used for
reply)... Oh, and how do you maintain state if the "connection" requires
multiple request/reply; heck, how do you ensure the file has a complete
request/reply before trying to read it?

Might be possible if the protocol emulates HTTP -- stateless; each
operation is a complete request/reply sequence and then all knowledge is
forgotten (needing a cookie in the request file to identify any needed
prior state).

But for general replacement of network "sockets" I don't see it...
The closest would be Popen() using pipes to communicate -- and just look
at how many problems get posted on trying to do "interactive" processing
with it. Of course, for your server, you need some way to tell the
server that a client wants to connect so both ends can identify a pipe.

 

[Thomas Jollans]

Hello,

I would like to create a python server for which the requests are
passed by files on the hard drive instead of a network.
I am currently looking at the SocketServer python module, hoping for
an easy modification.

Is it doable at all?
If yes, how should it be done?

If you're using UNIX, and you don't actually need the stream to be passed via
the hard drive (why would you?), but for some reason want to use the file
system, look info UNIX/local sockets. But, really, I'm guessing that local TCP
sockets (our old friend 127.0.0.1/8) will work just as well for whatever
you're doing (though I may be mistaken), are portable to non-UNIX system, and
won't be any slower than UNIX domain sockets on most, if not all, systems.

 

[John Nagle]

Hello,

I would like to create a python server for which the requests are
passed by files on the hard drive instead of a network.
I am currently looking at the SocketServer python module, hoping for
an easy modification.

Is it doable at all?
If yes, how should it be done?

Thanks,
Antoine.

Yes, it can be done. But why?

ICVERIFY, the first web-based credit card processing system,
worked that way. Remember web sites which put up messages
like "Wait up to 3 minutes for your credit card transaction to
be processed. DO NOT REFRESH THIS PAGE". That's ICverify.

The ICVERIFY concept was that the client-facing side created files
in an input directory, then waited for response files to appear.
The back end drove a farm of dial-up modems, each emulating a
1200 baud credit card terminal. Each back-end process looked
for incoming work files, marked them as in use, dialed up
the credit card processing system, did the transaction, and
wrote a response file. All the process coordination was
through files.

That was 1995 technology, before the banking system had
direct Internet connections.

John Nagle

 

[Nobody]

If you're using UNIX, and you don't actually need the stream to be
passed via the hard drive (why would you?), but for some reason want to
use the file system, look info UNIX/local sockets. But, really, I'm
guessing that local TCP sockets (our old friend 127.0.0.1/8) will work
just as well for whatever you're doing (though I may be mistaken), are
portable to non-UNIX system, and won't be any slower than UNIX domain
sockets on most, if not all, systems.

The problem with using the loopback interface is that it's still
"network access", which can run into all kinds of issues with security
policies, firewalls, etc.

 

[Thomas Jollans]

The problem with using the loopback interface is that it's still
"network access", which can run into all kinds of issues with security
policies, firewalls, etc.

What kind of crappy firewall blocks loopback traffic? Really?

 

[Nobody]

What kind of crappy firewall blocks loopback traffic? Really?

The sort that restricts the ability to create sockets rather than
filtering traffic. ZoneAlarm works like this.