home *** CD-ROM | disk | FTP | other *** search
/ rtsi.com / 2014.01.www.rtsi.com.tar / www.rtsi.com / OS9 / OSK / MISC / mtp.shar / ReadMe < prev   
Text File  |  2009-11-06  |  4KB  |  89 lines
  1.                    ================
  2.                    OPERATION OF MTP
  3.                    ================
  4.  
  5.  
  6. The OS-9 end is the server and the Sun end is the client.
  7.  
  8. The OS-9 system launches the daemon mtpd which creates a sokect listening at
  9. the port MTP_PORT.
  10.  
  11. When mtp is started on the Sun, it creates a socket and connects to MTP_PORT on
  12. the OS-9 system.
  13.  
  14. mtpd accepts the connection and forks a copy of mtpdc to handle the connection.
  15. mtpd then closes its compy of the connection and listens for another
  16. connection.
  17.  
  18. mtpdc interacts with the Sun programme mtp. Upon being forked it closes its
  19. copy of the master socket and then writes an acknowledge code into the socket.
  20.  
  21. mtp waits till it receives the acknowledge code before continuing.
  22. [HAVE TO HANDLE THE CASE WHEN NONE ARRIVES]
  23.  
  24. Interaction is then via a 1 byte code which specifies the action. Following
  25. bytes are code dependent. OS-9 acknowledges when it is finished (or ready) with
  26. the acknowledge code.
  27.  
  28. CODES
  29. -----
  30.  
  31. ACKNOWLEDGE     'a'    Sent by OS-9 server when it is ready
  32.  
  33. QUIT        'q'    Sent by client(mtp) to server(mtpd) to tell it that the
  34.             session is finished.
  35.  
  36. ERROR_CONTROL    'e'    Error. Followed by 4 bytes which are an integer in
  37.             network order specifying the error.
  38.  
  39.  
  40. PUTMOD        'p'    Put module from client file to server's memory.
  41.             Client sends PUTMOD followed by 4 bytes which are an
  42.             integer in network order specifying the number of bytes
  43.             in the module name., then that many bytes giving the
  44.             module name. Then the client sends 4 bytes ino giving
  45.             the module size. It then waits for the server to send
  46.             an ACKNOWLEDGE or an ERROR_CONTROL.
  47.                On getting a PUTMOD command, the server reads the
  48.             name size and the the name, and the module size. It
  49.             then unloads any module with this name and creates
  50.             space for it. If this can't be done an ERROR_CONTROL 
  51.             is sent to the client else an ACKNOWLEDGE is sent.
  52.                 On receiving the ACKNOWLEDGE the client then sends
  53.             all bytes for the module and waits for an ACKNOWLEDGE
  54.             or an ERROR_CONTROL. If it gets an ERROR_CONTROL back
  55.             at any stage it    must handle it properly.
  56.                  On getting the module and loading it into memory
  57.             the server then verifies it to load it into the module
  58.             directory. Once this is done the server sends an
  59.             ACKNOWLEDGE or an ERROR_CONTROL.
  60.                 That completes the module transfer.
  61.  
  62.  
  63. UPUTMOD        'u'    Same as PUTMOD except that no attempt is made to 
  64.             unload the module first. This is necessary for modules
  65.             in ROM which cannot be unloaded. But loading in a
  66.             module of the same name but a newer edition number will
  67.             result in the old version being dropped at the
  68.             verification stage.
  69.  
  70.  
  71. GETMOD        'g'    Get module from server's memory and put into file on
  72.             client.
  73.                 Client sends GETMOD followed by 4 bytes which are
  74.             an integer in network order specifying the number of
  75.             bytes in the module name, then that many bytes giving
  76.             the module name. It then waits for the server to send
  77.             an ACKNOWLEDGE or an ERROR_CONTROL.
  78.                On getting a GETMOD command, the server reads the
  79.             name size and the the name. It then links to the
  80.             module with this name and returns an ACKNOWLEDGE. If
  81.             there is no such file or an error occurs, an
  82.             ERROR_CONTROL is sent.
  83.                 If there is no error, the server next sends 4 bytes
  84.             in network order specifying the module size, followed
  85.             by that many bytes from the module.
  86.                 On receiving the ACKNOWLEDGE the client then reads
  87.             the module size and that number of bytes for the
  88.             module.
  89.