Yep, it's not quite as easy as it sounds - the handling of multiple modems
connected to a single server using denied-smsc-id is something that I'm yet
to see working correctly and writing a bug free program using locking with
mutexes is a fair amount of work.
Interesting point about the startup as well which means that you need to
have multiple message reading functionality regardless of whether you have
an active reader thread reading incoming messages and passing them out from
there.
This would also be an interesting opportunity to add code to pass back
result messages for message sending with a callback routine (http socket or
the like) as each message thread can resolve itself. More locking needed
there.
Does anyone know if Windows has any limitations on the amount of mutexes
available?
Alex
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Paul Keogh
|Sent: Thursday, July 19, 2001 12:14 PM
|To: [EMAIL PROTECTED]
|Subject: RE: At problem
|
|
|> The fundamental problem with the AT code is there is no queuing system
|> implemented either to process messages taken off of the SIM or to send
|> messages out through the SIM, and the current 'try for a
|> while then die'
|> mechanism is far from perfect.
|>
|
|I think its a bit more than that. Here are my suggestions;
|
|* Separate the AT I/O into a reader thread and a writer thread.
|
|* Make the writer thread event triggered. Define a set of events
|like { OK, ERROR, SIMPIN, PINREADY, PROMPT, TIMEOUT, LINEERROR }
|and so on. The writer thread should issue a command and wait for
|an event, and then take the appropriate action.
|
|* The reader thread reads characters from the port, parses the
|character stream into tokens and signals an event from
|the above set based on the token value.
|
|* New messages are handled by the reader thread, decoded into
|a Msg instance and placed on a List which is consumed by the
|higher level at_read...() function.
|
|You will need a rolling buffer struct for the read thread (something like
|the strstreambuf from the C++ STL) and a function to wait on
|multiple events (ie. Mutexes).
|
|Using the SIM as a buffer has pros and cons. You'll need more code
|to manage the device interaction (eg. to delete incoming messages
|from the SIM having read them). For consistency, you should also
|read messages from the SIM on start-up which means code to list
|messages and process the results of the list. In my experience,
|the less interaction with the devices, the more reliable the
|application tends to be.
|
|Hope this helps,
