Changes between Version 1 and Version 2 of Protocol Definition Language
- Timestamp:
- 02/06/12 13:24:59 (16 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Protocol Definition Language
v1 v2 1 This project includes and subsumes this older one "[wiki:"Improved encode/decode routines"]1 This project includes and subsumes this older one: [wiki:"Improved encode/decode routines"] 2 2 3 3 This project is to find an utilize or develop a protocol definition language or system to simplify the definition of the PVFS protocol. Currently the protocol definition starts with a set of structs in C that define the arguments passed in with each request, and back with each response and the overall structs that include these. Next each struct must have an encode and decode functions defined using a set of macros - and in some cases a new macro must be defined. Additional macros are created to fill in the structs and to define constants for declaring and checking the size of elements that have a variable length. These various parts are defined in several header files. It is easy for a change to miss one or more parts of this leaving the protocol potentially corruptible. … … 5 5 Another issue arises in that we would like to handle backwards compatibility when the protocol is updated. Currently a protocol major and minor number are manually maintained - the convention being that a client with an older minor number should be compatible with a server using a newer minor number. Major number mis-matches are assumed to be incompatible. There is no mechanism to tie these to specific protocol changes or to allow a broader range of compatibility. 6 6 7 Examples of similar systems to investigate are Google Protocol Buffers [http://code.google.com/apis/protocolbuffers/docs/overview.html] and rpcgen. While these are good examples, it is not likely they will be directly spplicable to PVFS. Google protocol buffers are for use with C++, Java, and Python, while PVFS is in C. Rpcgen uses XDR as an encoding, which is very similar to what is used in PVFS, but not identical.7 Examples of similar systems to investigate are [http://code.google.com/apis/protocolbuffers/docs/overview.html Google Protocol Buffers] and rpcgen. While these are good examples, it is not likely they will be directly spplicable to PVFS. Google protocol buffers are for use with C++, Java, and Python, while PVFS is in C. Rpcgen uses XDR as an encoding, which is very similar to what is used in PVFS, but not identical. 8 8 9 9 What we would like is to develop a simple C-like macro language that can be compiled into C code and compiled along with the client and server code. The protocol specification would largely replace the code in src/proto/pvfs2-req-proto.h and would define each request and its response with struct-like syntax including the request number definition, the request and response arguments, array arguments along with valid numbers of items in the array), version specifications indicating when a field is added for a specific protocol version. The compiler would automatically generate encode and decode functions for each request or response, including space management (allocation and freeing) and including reordering or insertion of padding to ensure proper 64-bit alignment, checks for invalid array counts and overflows, macros for filling in structs, code for handling different versions of the protocol, code for calculating the overall size of request and response buffers, etc. … … 40 40 The macro compiler can compile multiple protocol section with C code both before and after (and in-between). Struct definitions can exist in the main protocol definition, or in other files. The array notation is needed for several reasons including that the maximum size is needed and because arrays are general to be declared with a pointer and size. The protocol compiler can generate macros for assigning values to fields, especially arrays. THese declarations would both be used to generate the regular struct definitions and definitions needed for protocol processing such as encode and decode functions. 41 41 42 [wiki:"OrangeFS Projects" Back to OrangeFS projects page] 42 43 43 44
