jmurphy has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks,

I'm in the process (no pun intended) of writing a forking server. The purpose of the server is to read data from a serial port and write that data to a socket. I'd like to handle several simultaneous clients (all receiving the same data from the serial port). In the future clients will have the option of writing to the serial port via the socket however, that's not in the plan for version 1. BTW Lincoln Stein's book is excellent for anyone interested in network programming using Perl.

My problem is (or will be) access to the serial port (since only one process can access the port at any given time). Therefore I'm in search of design advice. My initial though was to divide the application into two main components:

1) The first component handles serial port I/O: Reading data from the port and writing data to the port.

2) The second component handles socket I/O: Writing data to the socket and reading data from the socket.

Assuming this is a valid design both components will need to talk to each other (pass data back and forth). I'm looking for an elegant solution (or design pattern) that will allow the "serial" component and the "socket" to pass data back and forth. Ideally I rather not have the "serial" component know anything about "clients" that need the data. Rather I'd like the "serial" component to write to some shared memory structure (for example) and then the "socket" component reads from that shared structure and writes the data to the clients.

Does anyone have any helpful design advice? Apologies for the long message.

  • Comment on Design Advice: Reading data from a serial port and writing it to multiple sockets.

Replies are listed 'Best First'.
Re: Design Advice: Reading data from a serial port and writing it to multiple sockets.
by submersible_toaster (Chaplain) on Sep 24, 2003 at 07:01 UTC

    Had I been tasked to do this (I'm keen to know what the application) I would consider Thread::Queue. I realise you mention writing a forker, it did not seem clear if that was a requirement or part of 'just-one-of' many possible designs.

    A 'serial' thread listens to the tty, dropping incoming data onto a queue. Checks a different queue for information from your socket process (TBD not in your requirements yet). A socket thread controls the multiple socket connections and relays any information arriving in the from-serial-thread queue.

    As always YMMV :)

    I can't believe it's not psellchecked
      Thanks so much. A "forker" isn't a requirement it's just that at the time I knew very little about ithreads. Lincoln's book is outdated in that respect but indispensable none the less. I really like your suggestion and I'm going to give it a try. Thanks again!