•  Back 
  •  System Services Protocol (SSP) 
  •  Index 
  •  Tree View 
  •  Cross references 
  •  Help page 
  •  Show info about hypertext 
  •  View a new file 
Topic       : TOS - das Betriebssystem
Author      : 
Version     : tos.hyp (5. März 2013)
Subject     : Programmieren/Atari
Nodes       : 3001
Index Size  : 93602
HCP-Version : 5
Compiled on : Atari
@charset    : atarist
@lang       : 
@default    : Titel
@help       : 
@options    : +g -i -s +x +zz -t4
@width      : 70
View Ref-File15.10.7  Timeouts and error handling                               TOS

There will be no SRA-side timeouts. Timing out will be handled 
completely on the Server side, because a) the SRA doesn't know about 
Immediate or Delayed Response Services, and b) depending on the SPA 
that might have to be started first, startup time may screw up SRA- 
side timeouts. Besides that, it takes even more work off the SRA's 
back ;)

Timing out between SSP_SRASR and SSP_SSA will be done by the SSP- 
Server, with consideration of startup times and IRS/DRS cases. The 
amount of time before a service times out will have to be determined 
once the first Server implementations and protocol implementations on 
application side are done. Approximately 3 to 5 seconds after possible 
startup of the SPA should be sufficient for IRS.

The Server will check all errors it can (nonexisting or empty shm- 
files, etc.). If an error during a session occurs, the Server will 
send SSP_SSA to the SRA to make sure the shm-file gets closed, and 
then report the error in an alert box. Timeout for delayed response 
services will depend on the type of service and on Server-side 
determinations. For example, If the SPA knows an error occured, it can 
send an error-message instead of SSP_SPASA. Still, in case of a crash 
of the SPA, a timeout has to be implemented.

Compress File Service timeouts can be done with consideration of the 
time between size changes of the archive file, opened and closed files 
or memory usage of the SPA. If none of the above changes, at some 
point it's safe to say that some error occured during performing the 
service (probably a crash of the SPA). In this case the Server could 
try to terminate what's left of the SPA, close shared memory files, 
clean up and close the communication session and start the whole thing 
over (Server-side retry). If that doesn't work, the Server will send 
@{"SSP_SSA" ignore} to the SRA to acknowledge and make sure the SRA 
frees temporary memory and closes shared memory files, and then 
display an error-message.