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

[Andrei Hutanu]

I find the padding a bit strange as well .. we should leave it out ..

Andrei

>> 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
>
>