SocketServer: replace network by hard drive

Discussion in 'Python' started by antoine, Sep 24, 2010.

  1. antoine

    antoine Guest

    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.
    antoine, Sep 24, 2010
    #1
    1. Advertising

  2. On Fri, 24 Sep 2010 00:53:22 -0700 (PDT), antoine <>
    declaimed the following in gmane.comp.python.general:

    > 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.
    --
    Wulfraed Dennis Lee Bieber AF6VN
    HTTP://wlfraed.home.netcom.com/
    Dennis Lee Bieber, Sep 24, 2010
    #2
    1. Advertising

  3. On Friday 24 September 2010, it occurred to antoine to exclaim:
    > 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.
    Thomas Jollans, Sep 24, 2010
    #3
  4. antoine

    John Nagle Guest

    On 9/24/2010 12:53 AM, antoine wrote:
    > 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
    John Nagle, Sep 24, 2010
    #4
  5. antoine

    Nobody Guest

    On Fri, 24 Sep 2010 19:28:45 +0200, Thomas Jollans wrote:

    > 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.
    Nobody, Sep 25, 2010
    #5
  6. On Saturday 25 September 2010, it occurred to Nobody to exclaim:
    > On Fri, 24 Sep 2010 19:28:45 +0200, Thomas Jollans wrote:
    > > 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.


    What kind of crappy firewall blocks loopback traffic? Really?
    Thomas Jollans, Sep 25, 2010
    #6
  7. antoine

    Nobody Guest

    On Sat, 25 Sep 2010 14:45:29 +0200, Thomas Jollans wrote:

    >> 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?


    The sort that restricts the ability to create sockets rather than
    filtering traffic. ZoneAlarm works like this.
    Nobody, Sep 26, 2010
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stephane Guyetant

    Hard Disk Drive behavioral model

    Stephane Guyetant, Oct 2, 2003, in forum: VHDL
    Replies:
    0
    Views:
    565
    Stephane Guyetant
    Oct 2, 2003
  2. Bruce W...1
    Replies:
    0
    Views:
    313
    Bruce W...1
    Aug 22, 2003
  3. mh
    Replies:
    4
    Views:
    698
    Wolfgang Strobl
    May 31, 2005
  4. shailesh
    Replies:
    1
    Views:
    777
    Tim Golden
    Mar 28, 2007
  5. king
    Replies:
    1
    Views:
    274
Loading...

Share This Page