Method for asynchronous application communication5327558Abstract In a general-purpose subscriber unit a data communication method provides management and control functions to allow communication between one of a plurality of software applications and a selected communication device, such as a radio frequency modem. Messages received by the modem may be routed and stored for designated ones of said applications, even if they are not currently active. Likewise, an application operating in background mode may generate messages which are stored, routed, and transmitted through the modem. Claims What is claimed is: Description RELATED INVENTIONS
__________________________________________________________________________
/* Startup and load manager */
PERFORM THE SESSION MANAGER START UP [A]
/* Terminate and Stay Resident */
Exit
/* when an interrupt occurs wake up and process */
CASE OF interrupt DO
CASE scheduler interrupt :
IF scheduler interrup is for "received messages"
THEN
HANDLE INBOUND MESSAGES [B]
ENDIF
IF scheduler interrupt is for "sending messages"
THEN
HANDLE OUTBOUND MESSAGES [D]
ENDIF
IF scheduler interrupt is for "application notification"
THEN
HANDLE APPLICATION NOTIFICATION SERVICE [G]
ENDIF ENDCASE
CASE serial port interrupt :
HANDLE SERIAL PORT INTERRUPTS [C]
CASE application interrupt :
HANDLE APPLICATION SERVICE REQUESTS [E]
CASE user interrupt/hot-key combination :
HANDLE SESSION MANAGER SHUTDOWN REQUEST [F]
OTHERS :
treat error
ENDCASE
__________________________________________________________________________
The Session Manager is loaded and started up by calling the routine PERFORM THE SESSION EAGER STARTUP 202. The Session Manager 28 Terminates and Stays Resident, waiting for an interrupt to occur. The interrupt causes the Session Manager 28 to "wake up" and process the type of interrupt that has occurred. When a scheduler interrupt occurs, the procedure HANDLE INBOUND MESSAGES 203 is called to handle any received messages, if the scheduler interrupt is for "received messages" The procedure HANDLE OUTBOUND MESSAGES 205 is called to handle any sent (posted) messages, if the scheduler interrupt is for "sending messages". The procedure HANDLE APPLICATION NOTIFICATION SERVICE 208 is called to notify the user or the application when in-bound messages arrive, if the scheduler interrupt is for "application notification". When a serial port interrupt occurs, the procedure HANDLE SERIAL PORT INTERRUPTS 204 is called to handle any event generated by the shared communication device connected through the serial port. When an application interrupt occurs, the procedure HANDLE APPLICATION SERVICE REQUESTS 206 is called to process the command set from an Application Programmer's Interface. When a user interrupt ("hot key" combination) occurs, the procedure HANDLE SESSION EAGER SHUTDOWN REQUEST 207 is called to terminate operation of the Session Manager 28 and unload the Session Manager 28 from memory. The occurrence of any other interrupt is treated as an error. Box SESS.sub.-- MGRA The pseudo-code listing for FIG. 7 comprises a procedure call-tree for the routine PERFORM THE SESSION MANAGER START UP 202. The procedure PERFORM THE SESSION EAGER START UP 202 calls the sub-procedures, GET SECOND LOAD STATUS 212, READ SESSION MANAGER CONFIGURATION FILE 213, GET HARDWARE INFORMATION 214, INITIALIZE SESSION MANAGER DATA 216, SETUP, CLEAN UP, AND PREPARE SESSION.sub.-- MGR TO TERMINATE AND STAY RESIDENT 217, and DISPLAY SIGNON SCREEN 218, in the sequence indicated in the pseudo-code listing below.
__________________________________________________________________________
GET SECOND LOAD STATUS [A]
READ SESSION MANAGER CONFIGURATION FILE [B]
GET HARDWARE INFORMATION [C]
INITIALIZE SESSION MANAGER DATA [E]
SETUP,CLEAN UP AND PREPARE SESSION.sub.-- MGR TO TERMINATE AND STAY
RESIDENT [F]
DISPLAY SIGNON SCREEN [G]
Box SESS.sub.-- MGRAA
__________________________________________________________________________
The pseudo-code listing for FIG. 8 comprises a procedure call-tree for the routine GET SECOND LOAD STATUS 212. The procedure GET SECOND LOAD STATUS 212 calls the sub-procedures, CHECK FOR SECOND LOAD OF THE SESSION MANAGER 222 and DISPLAY SECOND LOAD MESSAGE 223, to account for the situation that the Session Manager was loaded twice for execution.
__________________________________________________________________________
already.sub.-- loaded = CHECK FOR SECOND LOAD OF THE SESSION MANAGER [A]
IF already.sub.-- loaded
THEN DISPLAY SECOND LOAD MESSAGE [B]
exit
ENDIF
Box SESS.sub.-- MGRAAA
__________________________________________________________________________
The routine CHECK FOR SECOND LOAD OF THE SESSION MANAGER 222 (FIG. 8) verifies that the Session Manager 28 (FIG. 4) is not already loaded into memory, RAM 8 (FIG. 2). Box SESS.sub.-- MGRAAB The routine DISPLAY SECOND LOAD MESSAGE 223 (FIG. 8) displays a message to the User 126 (FIG.4) that the Session Manager 28 (FIG. 4) load was attempted twice. Box SESS.sub.-- MGRAB The pseudo-code listing for READ SESSION MANAGER CONFIGURATION FILE 213 (FIG. 7) is shown below. The Session Manager Configuration File 120 (FIG. 4) is opened. If it is opened without error, then storage is allocated for the Configuration Data Store 122. Parameters, such as communication parameters and notification attributes, are read from the Session Manager Configuration File 120 and written to the Configuration Data Store 122 and the Notification Attributes Data Store 123. If the Session Manager Configuration File 120 is opened with errors, an error message is displayed.
__________________________________________________________________________
IF Open session manager configuration file = OK
THEN
Allocate data structure for session manager configuration data
Read global parameters
Hot-key character
Communication parameters(COM Port, Baud rate)
Size of inbound queue (i.e. maximum number of stored messages)
Read applications' configuration:
Allication's session name
Notification attributes (pop-up,tone,interval)
Fixed user header
ELSE
Display error message
exit
ENDIF
Box SESS.sub.-- MGRAC
__________________________________________________________________________
The pseudo-code listing for FIG. 9 comprises a procedure call-tree for the routine GET HARDWARE INFORMATION 214. The procedure GET HARDWARE INFORMATION 214 calls routines GET MEMORY INFORMATION 232, GET DISPLAY ADAPTER INFORMATION 234, GET PC TYPE 235, and GET COMM PORT INFORMATION 236.
______________________________________
GET MEMORY INFORMATION [A]
GET DISPLAY ADAPTER INFORMATION [C]
GET PC TYPE [D]
GET COMM PORT INFORMATION [E]
Box SESS.sub.-- MGRACA
______________________________________
The pseudo-code listing for FIG. 10 comprises a procedure call-tree for the routine GET MEMORY INFORMATION 232. The procedure GET MEMORY INFORMATION 232 calls the sub-procedures, GET MEMORY SIZE 242 and GET MEMORY CONFIGURATION 243, to check whether memory minimal requirements are met. If there is not enough memory, an error message is displayed to the USER 126.
______________________________________
/* Check whether memory minimal requirements are met */
GET MEMORY SIZE [A]
GET MEMORY CONFIGURATION [B]
IF not enough memory available
THEN
display error message
exit
ENDIF
Box SESS.sub.-- MGRACAA
______________________________________
The pseudo-code listing for GET MEMORY SIZE 42 is shown below.
______________________________________
Get total memory size available for user applications,
i.e. maximum memory minus the memory size occupied by
DOS, TSR's etc.
______________________________________
The pseudo-code listing for GET MEMORY CONFIGURATION 243 is shown below.
______________________________________
Get the current configuration of memory
main memory
expended memory
Box SESS.sub.-- MGRACC
______________________________________
The pseudo-code listing for FIG. 11 comprises a procedure call-tree for the routine GET DISPLAY ADAPTER INFORMATION 234. The procedure GET DISPLAY ADAPTER INFORMATION 234 calls the sub-procedures, GET DISPLAY ADAPTER TYPE 262 and GET DISPLAY ADAPTER MODE 263, in the sequence indicated in the pseudo-code listing below. The original display setting is saved so that it can be restored when the Session Manager is terminated.
__________________________________________________________________________
GET DISPLAY ADAPTER TYPE [A] : may be MDA,CGA,EGA,MCGA,VGA
GET DISPLAY ADAPTER MODE [B] : TEXT,GRAPHICS (BW40,BW80,CO40,CO80)
No specific/minimal requirement for the display type and mode
Save original display setting in order to restore it once session
manager
is terminated
Box SESS.sub.-- MGRACCA
__________________________________________________________________________
The routine GET DISPLAY ADAPTER TYPE 262 (FIG. 11) retrieves the current display adapter type. Box SESS.sub.-- MGRACCB The pseudo-code listing for GET PC TYPE 235 (FIG. 9) is shown below. If the type of data processor is an IBM.TM. or compatible PC.TM. (Personal Computer), it must be at least the XT.TM. version or later; otherwise; an error message is displayed via the Notification Manager 40 and execution terminates.
______________________________________
Possible PC types that are PC,XT,AT,XT286
IF the PC type == PC
THEN
Display error message
exit
ENDIF
Box SESS.sub.-- MGRACE
______________________________________
The pseudo-code listing for FIG. 12 comprises a procedure call-tree for the routine GET COMM PORT INFORMATION 236. The procedure GET COMM PORT INFORMATION 236 calls the sub-procedures, GET COMM PORT ADDRESSES 272 and GET COMM PORT CONFIGURATION 273, in the sequence indicated in the pseudode listing below. If no serial port is available, then an error message is displayed via the Notification Manager 40. The original serial port .configuration is saved so that it can be restored when the Session Manager is terminated.
__________________________________________________________________________
GET COMM PORT ADDRESSES [A] : COM1,COM2 etc.
GET COMM PORT CONFIGURATION [B] : Baud rate,stop bit,parity etc.
IF no serial port is available
THEN
Display an error message
exit
ENDIF
Save original serial port configuration in order to restore it once
session manager is removed
Box SESS.sub.-- MGRACEA
__________________________________________________________________________
The routine GET COMM PORT ADDRESSES 272 (FIG. 12) retrieves the standard DOS COM Port 101 (FIG. 5) addresses. Box SESS.sub.-- MGRACEB The routine GET COMM PORT CONFIGURATION 273 (FIG. 12) retrieves the configuration (e.g. baud rate, parity, stop bits) for each port and stores it in memory, RAM 8 (FIG. 2). Box SESS.sub.-- MGRAE The pseudo-code listing for FIG. 13 comprises a procedure call-tree for the routine INITIALIZE SESSION MANAGER DATA 216. The procedure INITIALIZE SESSION MANAGER DATA 216 calls the sub-procedures, ALLOCATE INBOUND MESSAGE QUEUES FOR ALL CONFIG SESSIONS 292, ALLOCATE OUTBOUND MESSAGE QUEUES 294, INITIALIZE SCHEDULER EVENTS LIST 296, and INITIALIZE SOFTWARE TRAPS LIST 297, in the sequence indicated in the pseudo-code listing below.
__________________________________________________________________________
ALLOCATE INBOUND MESSAGE QUEUES FOR ALL CONFIG SESSIONS [A]
ALLOCATE OUTBOUND MESSAGE QUEUES [C]
INITIALIZE SCHEDULER EVENTS LIST [E]
INITIALIZE SOFTWARE TRAPS LIST [F]
Box SESS.sub.-- MGRAEA
__________________________________________________________________________
The expanded pseudo-code listing for ALLOCATE OUTBOUND MESSAGE QUEUES FOR ALL CONFIG SESSIONS 292 is shown below and is described in sufficient detail without further explanation.
__________________________________________________________________________
All sessions' inbound queues are handled in one pool.
Messages of a session are kept in a linked list.
Two pointers point to the head and tail of the memory pool.
A message is read from the serial port only if there is enough queue
pool
memory to store it(space is reserved for at least one message of
maximum
size i.e. 2K)
For each queue the following information is kept:
Number of messages in the queue
Number of bytes occupied by the queue messages
Pointer to the queue start
Each message is composed of the actual data and an extra word pointing
to
the next message in the queue.
Once the queue is full no more messages are read from the serial port,
letting the Shared Data Communication Device 30 (FIG. 5) NAK messages
as
its queues are overflown.
A message is issued to the user suggesting that no more room for
messages
is available in the session manager queues and unless an
application reads some of the waiting messages, new incoming host
messages will be NAKed.
In the cases of a graceful shutdown, all queue content is saved into
files
to be restored in case that the session manager is activated again.
Box SESS.sub.-- MGRAEC
__________________________________________________________________________
The pseudo-code listing for FIG. 14 comprises a procedure call-tree for the routine ALLOCATE OUTBAND MESSAGE QUEUES 294. The procedure ALLOCATE OUTBOUND MESSAGE QUEUES 294 calls the sub-procedures, ALLOCATE A SEND QUEUE (REGULAR MESSAGES) 302 and ALLOCATE AN EMERGENCY QUEUE (PRIORITY MESSAGES) 303, in the sequence indicated in the pseudo-code listing below. If an error occurs during the memory allocation for either queue, then an error message is displayed via the Notification Manager 40 and program startup is terminated.
__________________________________________________________________________
ALLOCATE A SEND QUEUE (REGULAR MESSAGES) [A]
IF memory allocation error
THEN
Display error message
exit
ENDIF
ALLOCATE AN EMERGENCY QUEUE (PRIORITY MESSAGES) [B]
IF memory allocation error
THEN
Display error message
exit
ENDIF
Box SESS.sub.-- MGRAECA
__________________________________________________________________________
The expanded pseudo-code listing for ALLOCATE A SEND QUEUE (REGULAR MESSAGES) 302 is shown below and is described in sufficient detail without further explanation.
__________________________________________________________________________
Outbound messages are kept in a linked list.
Two pointers point to the head and tail of the memory pool allocated for
the queue
A message is accepted and stored in this queue only if there is enough
for it, otherwise the session manager will return an error status
code to the application
For each queue the following information is kept:
Number of messages in the queue
Number of bytes occupied by the queue messages
Pointer to the queue start
Each message is composed of the actual data and an extra word pointing
to
the next message in the queue.
When the queue is full no more messages are stored in it, letting the
the session manager NAK the application "send" requests
A message is issued to the user indicating that something is wrong (host
not available, Shared Data Communication Device 30 (FIG. 5) low
battery, etc.)
Unless some action is taken to fix the problem source no messages will
be
stored by the session manager to be sent to the host.
In case of graceful shutdown all queue content is saved into a file to
be
restored in case the session manager is activated again.
Box SESS.sub.-- MGRAECB
__________________________________________________________________________
The expanded pseudo-code listing for ALLOCATE AN EMERGENCY QUEUE (PRIORITY MESSAGES) 303 is the same as in routine ALLOCATE ASEND QUEUE (REGULAR MESSAGES) 302 and is shown above. The pseudo-code is described in sufficient detail without further explanation.
__________________________________________________________________________
Same as in function ALLOCATE A SEND QUEUE (REGULAR MESSAGES).
Box SESS.sub.-- MGRAEE
__________________________________________________________________________
The pseudo-code listing for INITIALIZE SCHEDULER EVENTS LIST 296 (FIG. 13) is shown below. The routine INITIALIZE SCHEDULER EVENTS LIST 296 calls the scheduler (such as CodeRunneR.RTM., which is commercially available from Microsystems Software, Inc., Framingham, MA) to install the scheduler for real-time events handling. When the installation is complete, the events record for the Receive Task 107 (FIG. 5) , the Transmit Task 108 (FIG. 5) , and the Notification Task 124 (FIG. 4) is created.
__________________________________________________________________________
Call CodeRunneR's INSTALL.sub.-- SCH(service,stack.sub.-- size,lock.sub.--
mask) in order to
activate the scheduler
Box SESS.sub.-- MGRAEF
__________________________________________________________________________
The pseudo-code listing for INITIALIZE SOFTWARE TRAPS LIST 297 (FIG. 13) is shown below. The routine INITIALIZE SOFTWARE TRAPS LIST 297 calls the scheduler to install the API Manager 44 (FIG. 4) software interrupt trap routine. The software trap will be invoked when an application issues a request for an API service to the API ISR 116.
__________________________________________________________________________
Call CodeRunneR's INSTALL.sub.-- TRAP(trap.sub.-- service,stack.sub.--
size,lock.sub.-- mask) in order to
make software traps handling available
Box SESS.sub.-- MGRAF
__________________________________________________________________________
The pseudo-code listing for FIG. 15 comprises a procedure call-tree for the routine SETUP, CLEAN UP, AND PREPARE SESSION.sub.-- MGR TO TERMINATE AND STAY RESIDENT 217. The procedure SETUP, CLEAN UP, AND PREPARE SESSION.sub.-- MGR TO TERMINATE AND STAY RESIDENT 217 calls the sub-procedure ENABLE SERIAL PORT INT'S HANDLED BY THE SERIAL PORT MANAGER TASK 312.
__________________________________________________________________________
ENABLE SERIAL PORT INT'S HANDLED BY THE SERIAL PORT MANAGER TASK [A]
Box SESS.sub.-- MGRAFA
__________________________________________________________________________
The expanded pseudo-code listing for ENABLE SERIAL PORT INT'S HANDLED BY THE SERIAL PORT EAGER TASK 312 is shown below. The pseudo-code is described in sufficient detail without further explanation.
__________________________________________________________________________
Initialize the serial port setting all the related parameters (baud,
parity,
stop bits etc.)
Box SESS.sub.-- MGRAG
__________________________________________________________________________
The expanded pseudo-code listing for DISPLAY SIGN 0N SCREEN 218 (FIG. 7) is shown below. The pseudo-code is described in sufficient detail without further explanation.
__________________________________________________________________________
The sign on screen is displayed once the program is terminated and stays
resident.
The sign on screen is the product logo.
In the sign on screen, the name of the product and the version number is
displayed.
Box SESS.sub.-- MGRB
__________________________________________________________________________
The pseudo-code listing for HANDLE INBOUND MESSAGES 203 (FIG. 6) is shown below. When the scheduler interrupt is received, the routine begins execution. If at any point the routine "exits", execution stops until the next scheduler interrupt is received. In order to enable multiple applications 20, 22 to share a single Shared Data Communication Device 30 (FIG. 5), the invention has identified each application's communication "channel" as a session. A current session is the session that has control of the CPU 10 (FIG. 2) at that particular time. The invention employs loops and other program controls, as described below, to enable effective sharing of CPU time for all of the applications 20, 22, or sessions, that have a need to share the single Shared Data Communication Device 30 (FIG. 5). The routine first checks to see if any serial data is available, and if not, the routine exits and waits for the next scheduler interrupt. Otherwise, a loop is entered until the current session equals the start session--the first session that was originally processed. First the Shared Data Communication Device 30 (FIG. 5) is checked to get the number of waiting messages for the current session. If no messages are waiting for the current session, the next session in the cycle is checked for waiting messages. If there are messages waiting for the current session, they are read from the Receive Buffer 104 (FIG. 5), until it is empty, and copied into the current session's in-bound queue. That queue's pointers and counters are updated. A notification data structure is created by the Receive Task 107 (FIG. 5), and the application is notified directly (via interrupt) or it may be notified indirectly via the Notification Manager 40, that the current session has messages, or responses to messages, waiting. The current session is set to the next session in the cycle, the serial COM Port 101 (FIG. 5) is made available, and the routine exits, until the next scheduler interrupt occurs. This loop is performed until all sessions (applications) utilizing the invention have been serviced by processing the received messages.
__________________________________________________________________________
/* When EXIT is used this routine Terminates and Stays Resident until
next
event resumes it */
UPON INTERRUPT from the scheduler(periodic)
EXECUTE
IF no serial data is available (flag is set)
THEN exit
ENDIF
start.sub.-- session = current.sub.-- session
REPEAT
In local command mode query a predetermined register to get number
of waiting messages for the session
IF no waiting messages THEN
THEN
set current.sub.-- session to the next session
ELSE /* Messages are waiting so process these messages */
Go on-line for the current session
(which is already at handshake mode)
Delay for X time
(In order to let the Shared Data Communication Device 30
(FIG. 5) send automatically stored session's
messages to the DTE)
WHILE (DTE receive buffer is not empty)
DO
Read message (Which may be response or data)
Copy message into the session queue on the DTE
Update queue counters, pointers etc.
ENDWHILE
Go off-line into local command mode
Create a notification data structure for the current session
Name of application to notify
Session number which is being used by the application
Number of waiting messages
IF direct notification set for current session
THEN
Notify the foreground application directly
(setting a flag,using an interrupt call,...)
ENDIF
Set a notification event for the notification routine
(To perform the indirect notification)
Set current.sub.-- session to the next session in the cycle
Unblock the serial port
exit /* Hibernate until next time being executed */
ENDIF
UNTIL ( current.sub.-- session EQ start.sub.-- session )
ENDUNTIL
ENDEXECUTE
Box SESS.sub.-- MGRC
__________________________________________________________________________
The pseudo-code listing for HANDLE SERIAL PORT INTERRUPTS 204 (FIG. 6) is shown below. When a serial port interrupt is received, the routine begins execution. If the serial port interrupt is "transmit ready", then the next byte from the Transmit Buffer 105 (FIG. 5) was transmitted. If the serial port interrupt is "received byte", a data byte is read from the serial COM Port 101 (FIG. 5) and stored in the next free space in the Receive Buffer 104 (FIG. 5). Then a flag is set to indicate the arrival of serial data.
______________________________________
UPON INTERRUPT from serial port
EXECUTE
CASE OF serial port interrupt DO
CASE transmit ready :
Next byte from the transmit buffer is transmitted
CASE received byte :
Byte is read and stored into the next free slot in the
receive buffer
Set a flag to specify the arrival of serial data
ENDCASE
ENDEXECUTE
Box SESS.sub.-- MGRD
______________________________________
The pseudo-code listing for HANDLE OUTBOUND MESSAGES 205 (FIG. 6) is shown below. When a scheduler interrupt for the Transmit Task 108 (FIG. 5) is received, the routine begins execution. The routine begins by processing the Emergency (priority) Queue 115 (FIG. 4) first. The routine gets the priority message from the Emergency Queue 115 (FIG. 4) and sends it to the Shared Data Communication Device 30 (FIG. 5). The routine then receives a return status from the Shared Data Communication Device 30 (FIG. 5) indicating whether the send was successful. The Emergency Queue 115 (FIG. 4) variables are updated, and the message is cleared from the Emergency Queue 115 (FIG. 4). The routine continues processing the Emergency Queue 115 (FIG. 4) until it is empty. The routine exits, giving up control for other tasks which may be scheduled to run, after each priority message is processed, in order to handle any waiting incoming messages. The CPU 10 (FIG. 2) then returns control to this routine to continue emptying the Emergency Queue 115 (FIG. 4). The routine then repeats the same processing detailed above with the Regular Queue 114 (FIG. 4). The routine continues procession the Regular queue 114 (FIG. 4) until it is empty. The routine Terminates and Stays Resident (TSR) after each regular message is processed, in order to handle any waiting incoming messages or emergency outgoing messages. The CPU 10 (FIG. 2) then returns control to this routine to continue emptying the Regular Queue 114 (FIG. 4). When the Regular Queue 114 (FIG. 4) has been emptied, and all regular messages have been sent, processing stops for this routine until the next schedular interrupt is received.
__________________________________________________________________________
COMMENT
An event is set to resume this task once the user application
issues a "send message" service request. The scheduled event will
resume this task only if the CPU is free, otherwise it will occur each
clock tick until the CPU is release
ENDCOMMENT
/* When EXIT is used this routine exits until the next scheduler event
resumes it */
UPON INTERRUPT from the scheduler
EXECUTE
/* First handle emergency messages queue */
IF emergency queue is not empty
Get message from queue
Send the message to the shared data communication device
Get return status specifying that the message was successfully
sent to the shared data communication device
Update emergency queue related variables/counters
(# of messages, # of bytes used, head & tail pointers etc.)
Discard message from queue
ENDIF
/* Handled non-emergency messages queue */
IF send queue is not empty
Get message from queue
Send the message to the shared data communication device
Get return status specifying that the message was successfully
sent to the shared data communication device
Update send queue related variable/counters
(# of messages, # of bytes used, head & tail pointers etc.)
Discard message from queue
EXIT
ENDIF
ENDEXECUTE
Box SESS.sub.-- MGRE
__________________________________________________________________________
The pseudo-code listing for FIG. 16 comprises a procedure call-tree for the routine HANDLE APPLICATION SERVICE REQUESTS 206. The procedure HANDLE APPLICATION SERVICE REQUESTS 206 calls the sub-procedures, HANDLE MESSAGE RELATED SERVICE REQUESTS 322 and HANDLE NOTIFICATION RELATED SERVICE REQUESTS 323, in the sequence indicated in the pseudo-code listing below. When an application interrupt is received, the routine begins execution.
__________________________________________________________________________
IF application request is message related
THEN
HANDLE MESSAGE RELATED SERVICE REQUESTS [A]
ENDIF
IF application request is notification related
THEN
HANDLE NOTIFICATION RELATED SERVICE REQUESTS [B]
ENDID
Box SESS.sub.-- MGREA
__________________________________________________________________________
The pseudo-code listing for FIG. 17 comprises a procedure call-tree for the routine HANDLE MESSAGE RELATED SERVICE REQUESTS 322. The procedure HANDLE MESSAGE RELATED SERVICE REQUESTS 322 calls the sub-procedures, OPEN SESSION 332, CLOSE SESSION 333, DELETE SESSION 334, SEND MESSAGE 335, GET MESSAGE 336, and GET SESSION STATUS 337, when the request type is "open", "close", "delete", "send", "get", and "status", respectively.
______________________________________
CASE OF request type DO
CASE open :
OPEN SESSION [A]
CASE close :
CLOSE SESSION [B]
CASE delete :
DELETE SESSION [C]
CASE send :
SEND MESSAGE [D]
CASE get :
GET MESSAGE [E]
CASE status :
GET SESSION STATUS [F]
ENDCASE
Box SESS.sub.-- MGREAA
______________________________________
The pseudo-code listing for OPEN SESSION 332 (FIG. 17) is shown below. The pseudo-code is described in sufficient detail without further explanation.
______________________________________
Open an application's session and mark it active
Allocate and initiate session queues
Return a session handle
Box SESS.sub.-- MGREAB
______________________________________
The pseudo-code listing for CLOSE SESSION 333 (FIG. 17) is shown below. The pseudo-code is described in sufficient detail without further explanation.
______________________________________
Use a session handle to mark the session suspended
Keep handling session queues and inbound (received) messages
Box SESS.sub.-- MGREAC
______________________________________
The pseudo-code listing for DELETE SESSION 334 (FIG. 17) is shown below. The pseudo-code is described in sufficient detail without further explanation.
______________________________________
Identify session by its handle and mark it deleted
Empty all session queues and deallocate queue's memory
/* All queued messages are lost */
The user is requested to confirm session deletion
Box SESS.sub.13 MGREAD
______________________________________
The pseudo-code listing for SEND MESSAGE 335 (FIG. 17) is shown below. The pseudo-code is described in sufficient detail without further explanation.
__________________________________________________________________________
Get a data buffer to be sent as a message
Copy the data buffer content into a local data buffer
Store the message in the proper session's queue according to priority
(i.e.
emergency, regular)
Box SESS.sub.-- MGREAE
__________________________________________________________________________
The pseudo-code listing for GET MESSAGE 336 (FIG. 17) is shown below. The pseudo-code is described in sufficient detail without further explanation.
__________________________________________________________________________
Get a message (if one exists) from the proper session's queue (i.e. a
message
or response)
Copy the message to the application's data buffer allocated by the
application
Discard message from the local queues
Box SESS.sub.-- MGREAF
__________________________________________________________________________
The pseudo-code listing for GET SESSION STATUS 337 (FIG. 17) is shown below. The pseudo-code is described in sufficient detail without further explanation.
______________________________________
Return status information regarding the session, such as number
of stored messages in each queue, session active/suspended status,
etc.
Box SeSS.sub.-- MGREB
______________________________________
The pseudo-code listing for FIG. 18 comprises a procedure call-tree for the routine HANDLE NOTIFICATION RELATED SERVICE REQUESTS 323. The procedure HANDLE NOTIFICATION RELATED SERVICE REQUESTS 323 calls the sub-procedures, SET NOTIFICATION PARAMETERS 342 and GET NOTIFICATION STATUS AND PARAMETERS 343, when the request type is "set parameters" or "get status", respectively.
__________________________________________________________________________
CASE OF request type DO
CASE set parameters :
SET NOTIFICATION PARAMETERS [A]
CASE get status :
GET NOTIFICATION STATUS AND PARAMETERS [B]
ENDCASE
SESS.sub.-- MGREBA
__________________________________________________________________________
The pseudo-code listing for SET NOTIFICATION PARAMETERS 342. (FIG. 18) is shown below. The pseudo-code is described in sufficient detail without further explanation.
__________________________________________________________________________
Get the new values for the notification attributes such as visual
notification,
audible notification, and direct notification
Store the values in the Session Manager configuration record
Box SESS.sub.-- MGREBB
__________________________________________________________________________
The pseudo-code listing for GET NOTIFICATION STATUS AND PARAMETERS 343 (FIG. 18) is shown below. The pseudo-code is described in sufficient detail without further explanation.
__________________________________________________________________________
Fetch the requested value of the notification attribute from the Session
Manager
configuration record.
Return the requested attribute to the requesting application.
Box SESS.sub.-- MGRF
__________________________________________________________________________
The pseudo-code listing for FIG. 19 comprises a procedure call-tree for the routine HANDLE SESSION MANAGER SHUTDOWN REQUEST 207. The procedure HANDLE SESSION MANAGER SHUTDOWN REQUEST 207 calls the sub-procedures, TERMINATE AND DELETE ALL SESSIONS 352, STORE INBOUND QUEUES' MESSAGES TO DISK FILES 353, STORE OUTBOUND QUEUES' MESSAGES TO DISK FILES 354, RESTORE SERIAL PORT ORIGINAL CONFIGURATION 355, RESTORE DISPLAY ORIGINAL CONFIGURATION 356, and UNLOAD SESSION MANAGER 358, in the sequence indicated in the pseudo-code listing below. The pseudo-code is described in sufficient detail without further explanation.
__________________________________________________________________________
/* Handle active session shutdown */
IF there is/are any active session(s)
THEN
TERMINATE AND QUIT ALL SESSION [A]
STORE INBOUND QUEUE' MESSAGES TO DISK FILES [B]
STORE OUTBOUND QUEUE' MESSAGES TO DISK FILES [C]
ENDIF
/* Restore the PC to its original configuration */
RESTORE SERIAL PORT ORIGINAL CONFIGURATION [D]
RESTORE DISPLAY ORIGINAL CONFIGURATION [E]
/* Free memory occupied by the session manager */
UNLOAD SESSION MANAGER [G]
Box SESS.sub.-- MGRG
__________________________________________________________________________
The pseudo-code listing for HANDLE APPLICATION NOTIFICATION SERVICE 208 (FIG. 6) is shown below. When a scheduler interrupt is received, the routine begins execution. The routine retrieves the notification data for the current session. If direct notification is enabled for the current session, then the direct notification flag is set in the application address space or an application's designated call-back routine is called; otherwise, nothing is done. The routine retrieves the internal Notification Attributes 123 (FIG. 4) to generate an indirect notification to the User 126 (FIG. 4) for the current session.
__________________________________________________________________________
COMMENT
Notification data is prepared by the Message Manager Receive Task
as messages are being received for a session. This data is
placed in a predetermined memory location which is accessible to this
function.
ENDCOMMENT
UPON INTERRUPT from the scheduler indicating to invoke the Notification
Manager
EXECUTE
Get the current notification data structure
(application name,session number,number of waiting messages)
IF Direct notification is enabled for the application
THEN
Set direct notification flag in the application address space or
call a dedicated call-back routine designated by the application
to handle its notification events.
ELSE
ENDIF
Look-up in Notification Attribute data store which attributes to set
for the indirect notification(pop-up,tone,interval)
ENDEXECUTE
__________________________________________________________________________
It will be apparent to those skilled in the art that the disclosed invention may be modified in numerous ways and may assume many embodiments other than the preferred form specifically set out and described above. For example, the transceiver devices may communicate with each other in any suitable manner, as described with reference to FIGS. 22-23. FIG. 20 shows a block diagram depicting a pair of transceivers communicating via direct radio frequency signals in accordance with another embodiment of the invention. Devices 75 and 85 send and receive RF signals 90 directly via modems 70 and 80 to each other in order to transfer data from one to the other. FIG. 21 shows a block diagram depicting a pair of transceivers communicating via telephone line in accordance with another embodiment of the invention. Devices 31 and 32 send and receive data to and from each other via modems 36 and 37, communications infrastructure 33, and telephone lines 34 and 38. FIG. 22 shows a block diagram depicting a pair of transceivers communicating via direct wireline in accordance with another embodiment of the invention. Transceiver devices 41 and 42 exchange data over direct wireline 46. FIG. 23 shows a block diagram depicting a pair of transceivers communicating via infra-red communication links in accordance with another embodiment of the invention. Devices 51 and 52 send and receive data to and from each other via infra-red (IR) transceivers 53 and 54. The data is transferred utilizing IR signals 56 and 57. Operation of a Preferred Embodiment With reference now to FIGS. 3-5, the operation of the invention will be described regarding the asynchronous receipt of a message by an application. Upon receiving data from the RF Modem 30, the COM ISR 103 in the Device Manager 48 reads it and writes it to its Receive Buffer 104. Periodically the Device State Machine Task 106 is invoked by the Scheduler 102 "looking" for new data to either receive or transmit. When new data is found in the Receive Buffer 104, it is copied to an application's corresponding In-bound Queue 109 by the Receive Task 107 in the Message Manager 47. The data message is stored in this queue until the user 126 directs the application 20 to issue a receive command via the Command Library 24. Such an API request interrupts the API ISR 116 in the API Manager 44. The API ISR will interpret the request and will retrieve the pending data message from the In-bound Queue 109 in the Queue Manager 47, passing it to the requesting application 20. So long as a request is not issued, the data message is stored in the Queue Manager queue. Other data messages can also be stored in the same queue before any of them are read by the application 20. Also data messages for different applications may be stored in their corresponding queues and not be lost until read. In addition, a given application may have opened more than one session, so each of its sessions is allocated a respective queue for the temporary storage of messages or commands being transmitted to or from such application. The operation of a preferred embodiment of the invention will now be described regarding the asynchronous transmission of a message by an application. A user can use an application to send a data message, calling the API service in charge of message sending. Once control gets back to the application, the user may exit the application, perform other operations using the application, or even start sending another message. In the background, the message is received by the API Manager 44 and written to the correct Out-Bound Queue according to its priority, regardless of what happens in the foreground. The Session Manager's Message Manager 43 will poll the outbound queues to check for something to transmit. Since in this case a data message is pending transmission, it will be removed from its queue and written into a low level Transmit Buffer 105. This buffer is polled by yet another periodical task, the COM ISR 103 which in turn sends the data message to the RF Modem 30 via the Com Port 101. The entire operation is unaffected by what the sending application may now be doing or by the currently inactive status of the sending application. Thus it will be seen that the present invention provides a method for enabling a general-purpose subscriber unit, such as a portable computer, to receive and transmit messages to and from applications in background mode. The invention eliminates the need for an application to remain active during message transmission or reception, because it performs the transmission or reception of messages on behalf of the application, even if the application is no longer running. The computer program portion of a preferred embodiment of the present invention incorporates a unique combination of traditional programming elements: background daemons, interprocess communication using mailboxes, client/server partitioning, operating system interprocess communication techniques, real-time programming, and wireless data communication. It will be apparent to those skilled in the art that the disclosed invention may be modified in numerous ways and may assume many embodiments other than the preferred form specifically set out and described above. Accordingly, it is intended by the appended claims to cover all modifications of the invention which fall within the true spirit and scope of the invention.
|
Same subclass Same class Consider this |
||||||||||