[saga-rg] Re: Meeting Notes: Messaging API

[John Shalf]

On Dec 4, 2005, at 3:49 PM, Pascal Kleijer wrote:

> Hello,
>
> Just one comment to the read proposal:
>
> "where size is passed to the read method, if size is smaller then  
> the real message size, message gets truncated, remainder gets lost  
> (read again not possible). If size is larger, buffer gets patted by 0"

Hi Pascal,
the truncation is obviously necessary to prevent buffer-overflow  
attacks (either accidental or intentional).  The padding for  
oversized buffers is new to me as well. I know that this is done  
inside of security-oriented software like LibSSH (always zero-padding  
buffers on short-reads).  I assume there is some security reason for  
doing this, but would appreciate any insight from others on the list  
as to whether the return size for the short read (that indicates the  
correct message size) is sufficient.

> Tailing 0s are unnecessary if the read returns the number of bytes  
> that were read. It is a waist of CPU time to do that. The buffer  
> that is unused should remain "as is".
>
> Another issue is that this API forces to write/read the message  
> into/from the first offset of the buffer. In languages like java it  
> ain't be possible to shift the pointer like in C, so the offset  
> must be explicitly given.

Good point.  This may need to be dealt with for the fortran bindings  
as well in order to be correct to the standard. (we can pass array 
(offset) and it will work for an underlying c-implementation, but  
that might be an abuse of the standard).

> Again this is a language binding issue, but it could be put in the  
> API, otherwise the implementations will not have the same  
> signatures. We will then end up with implementations that do not  
> reflect the generic API for most functions.
>
>
> Andrei Hutanu wrote:
>> I compiled all the notes on the wiki  : http://wiki.cct.lsu.edu/ 
>> saga/space/SAGA+API/Messages
>> Andrei
>> Andre Merzky wrote:
>>> Hmm, that is what I initially wanted to say :-)  I should
>>> have marked in/out params more clearly...
>>>
>>> A.
>>>
>>>
>>> Quoting [John Shalf] (Nov 22 2005):
>>>
>>>> Whoops,
>>>> then we really need
>>>>     a) size is not known, so we do two step
>>>>     int getMessageSize(handle);
>>>>     <malloc by application>
>>>>     int read(handle,buffer,size)
>>>>
>>>>     b) size is not known, but we let implementation malloc  
>>>> automatically
>>>>     char *readAutoAllocate(handle);
>>>>
>>>>     c) size is known, so we just do a one-step read
>>>>     int read(handle,buffer,size);
>>>>
>>>
>>>
>>>
>>>
>
>
> -- 
>
> Best regards,
> Pascal Kleijer
>
> ----------------------------------------------------------------
>   HPC Marketing Promotion Division, NEC Corporation
>   1-10, Nisshin-cho, Fuchu, Tokyo, 183-8501, Japan.
>   Tel: +81-(0)42/333.6389       Fax: +81-(0)42/333.6382