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.3 SSP messages TOS Messagesare currently undefined. Free AES message numbers have to be found and the SSP messages defined. 1. Service Requesting Application Service Request #define SSP_SRASR 0x126F SRA -> Server AES message-buffer: [0] = SSP_SRASR [1] = appl_id - Application ID of SRA [2][3] = (long)dataLen - LONG that gives length of data in the shm-block [4] = dataID - Data identification (SSP_TEXT, SSP_FILENAME ...) [5] = shmID - ID number for shared memory file Filename for shm-file is u:/shm/[applid]_data[id].ssp For example, if Smurf has appl_id 25, is sending a file and chose id 0: u:/shm/25_data0.ssp The shm-block contains data to be transferred: SSP_COMPRESSFILE: Complete Filepath, including name and extension SSP_SENDFILE: Complete Filepath, including name and extension SSP_UPLOADFILE: Complete Filepath, including name and extension SSP_SENDMSG: Complete text message to be sent [4] is important to the Server. Since the SRA doesn't have any influence on the selection of services by the user, the SRA has to tell the Server what the shared memory block contains, so that the Server can decide which services apply to the data, how these services are to be handled and what to send to the SPA, especially when combining services. This is all the SRA has to do. The Server will open popups/dialog windows for choosing possible services and service providing applications - open shared memory file with Fcreate and Fcntl, Fclose - send SRASR message to SSP-Server 2. Server Service Initialization Request #define SSP_SSIR 0x1270 Server -> SPA AES message-buffer: [0] = SSP_SSIR [1] = requestID - ID of Server request (SSP_RECIPIENTS, SSP_COMPRESSFORMAT...) [2] = sessionID - ID of SSP session Filename for shm-file is u:/shm/[applID]_init[sessionID].ssp For example, if aICQ is to send a file to another user, [1] will contain SSP_RECIPIENTS. aICQ is then to open an shm-file with the name built by the above conventions: u:/shm/32_init0.ssp (given aICQs appl_id is 32), containing a list of recipients (nicknames) separated by CRLF terminated by NULL. requestID will only contain values for possible services for the SPA, as transmitted to the Server upon SSP initialization (e.g. aICQ will only receive SSP_RECIPIENTS for SSP_SENDFILE and SSP_SENDMSG). The SPA has to respond with SSP_SPASI. 3. Service Providing Application Service Initialization #define SSP_SPASI 0x1271 SPA -> Server AES message-buffer: [0] = SSP_SPASI [1] = sessionID - ID of SSP session as given in SSP_SSIR The Server holds the status of each session and can hence determine by the sessionID the name of the shm-file to open and the type of data that it contains. In the SSP_SENDFILE / SSP_RECIPIENTS case, the Server will retrieve the list of recipients from the file and open a popup/dialog, listing them. After the user picks a recipient, the SPA will receive SSP_SSUR: 4. Server Service Use Request #define SSP_SSUR 0x1272 Server -> SPA AES message-buffer: [0] = SSP_SSUR [1] = serviceID - ID of service (e.g. SSP_SENDFILE) [2] = sessionID - ID of SSP session as given in SSP_SSIR [3][4] = (long)initID - ID of picked initialization datum [5] = shmID1 - ID 1 for shm-block [5] = shmID2 - ID 2 for shm-block [7] = sspPar1 [8] = sspPar2 The SPA can then open the file u:/shm/[shmID1]_data[shmID2].ssp (e.g. 25_data0.ssp) and retrieve the data, initID is the number of the initialization datum chosen by the user, for a ICQ sendfile it would be the number of the recipient out of the list it transmitted in SSP_SPASI. 1 would be the first recipient, n the n-th. The shm file contains: SSP_COMPRESSFILE: Complete filepath, including name and extension SSP_SENDFILE: Complete filepath, including name and extension SSP_UPLOADFILE: Complete filepath, including name and extension SSP_SENDMSG: Complete text message to be sent sspPar1 and sspPar2 are parameters set by the Server that indicate what to do. For SSP_SENDFILE, both are unused. For SSP_COMPRESSFILE sspPar1 would be the ID of a shared memory file (u:/shm/cffile[ssPar1].ssp) that contains the filename to pack the archive to. For SSP_UPLOADFILE sspPar1 would be the ID of a shared memory file u:/shm/uplfile[sspPar1].ssp) that contains the directory name to upload the file to on the chosen Server (initID). The SPA is to copy or use the data contained in the shm-block as quickly as possible, and then send SSP_SPASA back to the Server. After that, the service should be performed (see also Immediate Response and Delayed Response services!) 5. Service Providing Application Service Acknowledge #define SSP_SPASA 0x1273 SPA -> Server AES message-buffer: [0] = SSP_SPASA [1] = sessionID - ID of SSP session as given in SSP_SSIR This acknowledges performing the service and closes the current session. Finally, the Server will send SSP_SSA to the SRA, after receiving SSP_SPASA: 6. Server Service Acknowledge #define SSP_SSA 0x1274 Server -> SRA AES message-buffer: [0] = SSP_SSA [1] = dataID - ID of data shm file as given in SSP_SRASR This indicates that the service is performing or has been performed, and the SRA can close and delete the shared memory file u:/shm/[appl_id]_data[dataID].ssp (e.g. 25_data0.ssp) using Fdelete.