Re: [llnl-devel] Re: [Freeipmi-devel] kcs byte array model - validation

[Anand Babu]

I instantly got what you hand in your mind, the moment you mentioned
you wanted to hide marshalling from the user. Looks like this is what
I also proposed in Al's reply.

switch(CMD-TYPE) where in our case CMD-TYPE is command number.
-ab

,----[ "Mark A. Grondona" <address@hidden> ]
|  > Mark Grondona made an excellent suggestion of hiding the
|  > marshalling call behind. I meets both of our goals.
| 
| Yeah, I did mean to say that receiving messages is more difficult than
| sending data. In fact, I'd say that sending network protocol data is
| near trivial compared to receiving.
| 
| Something I am experimenting with now is an interface that looks
| similar to:
| 
| 
|  struct foo_msghdr { foo_msg_type_t msg_type; void *data; };
| 
|  ...
| 
|  struct foo_msghdr hdr[1];
|   
|  foo_recvmsg (foo_connection_t server, hdr);
| 
|  switch (hdr->msg_type) { case FOO_MSG_RESPONSE: process_foo_msg_resp
|     ((foo_msg_resp_t *)hdr->data); break; ...
| 
|  foo_free_msg_data (hdr);
|  
|  
| In this implementation, the hdr is filled in with the type of message
| most recently received and data contains the message which has already
| been unmarshalled from a network buffer. The message data is freed
| with foo_free_msg (), which contains no reference to how the memory
| was allocated, so that this implementation detail can change without
| breaking the API.
| 
| foo_msg_type_t can also contain other message events such as
| FOO_MSG_ERROR, FOO_MSG_EOF, etc for indicating non-message events over
| the connection `c'.
| 
| Of course the above implementation may be too functionally terse for
| your project, but I'd thought I'd share.
`----

-- 
Anand Babu
CaliforniaDigital.com
Office# +1-510-687-7045
Cell# +1-510-396-0717
Home# +1-510-894-0586

Free as in Freedom <www.gnu.org>