31/05/2000 00:33:27 -0500 Memory Information eXchange Specifications version 1 by Dave Poirier http://ekspace.isuisse.com/mi/ Introduction ------------ The Memory Information eXchange specifications is a document to explain how it is used, where and why it was needed. This document isn't a tutorial nor a standard. It is simply a guide that I hope, will help the development community better exchange information between application, with greater efficiency and ease. History ------- The idea germinated when I agreed to make my assembler accept source file directly from memory. I needed a way to efficiently exchange information and also return some error codes, possibly complete error description. A bit of research on the subject revealed that moving the whole source from one point in memory to another was too inefficient to be used, so we had to transfer only pointers. The principle worked well, I had a beta version of an editor, which was returning a pointer to the source file, I was able to analyze this file with my assembler and return the result of the compilation to an pre-determined area. This worked well, but that wasn't satisfying me, I was feeling like I would soon run into problem. Some of the problems foreseen where exchanging binary information (not only text), working in a restricted memory environment and using the same interchange format for other types of applications. I needed a stronger, more defined and consise way of exchanging information, this document present the result of these researchs. Table Of Content ---------------- 1. Application of the Memory Information eXchange 2. Sample procedure of a transfer using the proposed model 3. MiXB-Memory Information eXChange Block 4. Contacting me 5. About this document 1. Application of the Memory Information eXchange ------------------------------------------------- The memory information eXchange specifications could be followed by any application or process, that would like to exchange information in a global shared memory environment. It could also be used in an environment sharing a common data addressing space. The current specifications allow to define both a source information area and a feedback area with variable size and location. When using the current specifications, an application does not have to transfer anything more than pointers to these two areas, and general informations required to track the transaction. 2. Sample procedure of a transfer using the proposed model ---------------------------------------------------------- The following procedure could describe an average transaction in a globally shared memory addressing space. The term 'sender' define the application initiating a transfer while the term 'receiver' define the application that will accept the transfer and process or redirect the informations transfered. sender 1. Allocate a memory block big enough to store a the MiXB (Memory Information eXchange Block, see section of the same name) 2. Mark the allocated block as using the current specification signature 3. Fill in the 'source' pointer with the address in global space where the information for the receiver are stored 4. Fill the 'source_size' with the quantity, in bytes, of information that the sender is sending to the receiver 5. Fill in the 'feedback' pointer with the address in global space where the sender would like to receive informations coming back from the receiver 6. Fill in the 'feedback_size' with the total space available for the receiver to store information for the sender 7. Fill the 'name' field with the name of the current object or transfer. This could also represent a transaction number 8. Initialize the transfer by sending the pointer to the MiXB to the receiver. receiver 1. Make sure the pointer receive is valid and identify transfer format version by looking at the MiXB's signature 2. If an invalid block is detected, transfer is cancelled 3. Load the 'source' pointer using the 'source' field in the MiXB structure 4. Load the 'feedback' pointer using the 'feedback' field 4. Process the source information pointed to by the 'source' pointer 5. Return any feedback or return information to the destination pointed to by the 'feedback' pointer 6. Invert the MiXB signature, to mark the transfer as executed. Those of you familiar with multi-tasking environment will notice that the sender only have to check periodically the MiXB signature in order to know if yes or no a transfer is complete. In a real-time environment, a timer could be started when the transaction is initiated and the transfer state checked periodically. If the timer expire before the transaction is completed, we have a failure in transaction. This could either mean that the receiver didn't have enough time to process the information sent, or that the receiver simply does not support the current interchange format. In a single process environment, the signature could be checked on the return from the receiver. If the signature isn't inversed, the receiver does not support the currently used interchange format. Since it's a single process environment, the case where the receiver didn't have enough time to process the information is eliminated, leaving only unsupported transaction as a possible fault. 3. MiXB-Memory Information eXChange Block ----------------------------------------- note: all values are in hexadecimal offset size description ------ ---- ----------- 0000 4 MiXB signature: Mi01 0004 4 Pointer to 'source' information 0008 4 Size of the 'source' information block 000C 4 Pointer to 'feedback' reserved space 0010 4 Size of the 'feedback' reserved space 0014 20 Name of the current transaction MiXB signature -------------- The signature serve two purpose: 1. Validate the pointer to the MiXB 2. Identify which version of the MiX is used The signature for the current specifications is 'Mi01'. Please note that this field is case sensitive. So 'Mi01' isn't the same as 'mi01' or 'MI01'. Pointer to 'source' information ------------------------------- An offset in the global/local shared space to the information block to be passed to the receiver. Size of the 'source' information block -------------------------------------- The size in bytes, of the information block to be sent. This field could be used to specify a certain quantity of information to send in a tcp/ip packet or the size of binary file to be stored on disk. Pointer to 'feedback' reserved space ------------------------------------ An offset in the global/local shared space to a block of memory, reserved for the receiver, where this last one may put any return information destined to the sender. An offset of -1 could be used to specify that no feedback is required from the receiver. Size of the 'feedback' reserved space ------------------------------------- The size in bytes of the block of memory that has been reserved for the receiver to use. An offset of 0 could indicate that no feedback is required from the receiver. Name of the current transaction ------------------------------- Depending on the application, this field could be used to store an transaction number, identification name or any meaningfull information that may help the sender and receiver to track their transaction. This field can be either a 0-terminated string, or a very long binary number (stored little indian). 4. Contacting me ---------------- If you have any comments or suggestions, need more information or simply want to annoy me, here's a few information that may help you find me. name: Dave Poirier, a.k.a.: EKS e-mail: futur@mad.scientist.com website: http://ekspace.isuisse.com/ irc: #v2os and #v2os.dev on EFnet 5. About this document ---------------------- This document may be distributed or reproduced as long as it's freely available on at least one electornic network open to the general public and that all copy are kept integral. A small fee covering the reproduction cost may be charged for physical copy of this document. eof