Soliciing suggestions for application design

[Byron Morgan]

Carl, thanks for your interest. Further background:

- Platform is W2K

- I don't see how I could do it single-threaded, as I need to be able to
note the precise time each poll is detected going out, and the time each
response is received - there is no other way of associating the
poll-response pairs.

- The frequency of polling is unpredictable, as is the likelihood of a
response coming in. This is a data controlled radio system, and my program
will be listening, not controlling anything.

- The 'something interesting' is just string manipulations to reveal the
encoded data of the poll-response sets. The task at hand is to capture the
essence of this data, which is running on a 20- year- old legacy system,
without encumbering the system itself with additional overhead.

- Frequency of polling is approximately 400-500 / minute

"Carl Banks" <imbosol-1048379651 at aerojockey.com> wrote in message
news:gC7fa.79085$gi1.28851 at nwrdny02.gnilink.net...
> Byron Morgan wrote:
> > Greetings all,
> >
> > I need to build an app to do the following:
> >
> > 1. monitor two serial ports: port A polls for data, B carries responses
from
> > a population of 1000 mobile radios
> > 2. match polls to responses based on timing window (between .033 & .066
> > seconds) after poll is transmitted
> > 3. do something interesting to selected poll - response pairs
> > 4. forward results via inet (as telnet stream or cgi post, not decided
yet)
> >
> > Should I try to do it all in a single program, using threading (haven't
> > tried threading yet), or use a parent app to do the interesting stuff
and
> > two children to monitor the ports and supply the data? If the latter,
how
> > best to handle the interprocess comms? I haven't started experimenting
with
> > the live data yet, but it seems to me the single most important part
will be
> > to get the timing stuff right (can't be off doing something else while a
new
> > message is waiting to be read).
> >
> > All suggestions on architecture and methodology greatly appreciated by
this
> > Python newbie.
>
> We could answer you better if you could also tell us:
>
> 1. Why you've ruled out a single-threaded program (if you did).
> 2. How frequently you poll.
> 3. Roughly what kinds of interesting things you do with the results.
>    How time consuming are they?
> 4. What platforms do you want this to work on?
>
>
> If this is just big mobile radio ping (in other words, if you never
> poll except when the user requests it), then I'd just make it
> single-threaded.  I'd say this is the best option for getting the
> timing right.  You might want to open the serial ports in exclusive
> mode (if your platform has that kind of thing) so two invocations
> can't try to poll at once.
>
> If the polling is done automatically, and rather often, I would
> probably make it multithreaded, and use the Queue module to hand off
> raw serial port data to the thread that does interesting things
> with it.
>
> How you would do interprocess communication is highly system dependent
> and depends on how much data we're talking about.
>
>
> --
> CARL BANKS