On 3/13/2012 4:26 PM, Steven Dake wrote:
> On 03/13/2012 07:44 AM, Fabio M. Di Nitto wrote:
>> From: "Fabio M. Di Nitto" <fdinitto@xxxxxxxxxx>
>>
>> totem doesn't need to understand what crypto does.
>>
>> totem needs to be able to tell crypto: "those are data, play with them"
>> and crypto needs to return: "here are your scrambled data and the new size"
>>
>
> crypto should take a max size (the network mtu) and ensure that what it
> will only take an input that would product a maximum packet size. This
> is not trivial. I suggest having a call within crypto to return the
> extra blob data needed by the crypto code to hit the mtu size.
This is exactly how it has been done :)
>
> What we want to avoid is ever sending packets larger then the MTU
> because while udp can send up to 64k byte messages, when networks are
> lossy it can trigger problems in totem to have udp-fragmented packets.
Yup. Very well aware of the problem.
>> #define UDPIP_HEADER_SIZE (20 + 8) /* 20 bytes for ip 8 bytes for udp */
>> if (totem_config->secauth == 1) {
>> - totem_config->net_mtu -= sizeof (struct crypto_security_header) +
>> + totem_config->net_mtu -= crypto_sec_header_size(totem_config->crypto_hash_type) +
>> UDPIP_HEADER_SIZE;
crypto_sec_header_size returns the size of the crypto_security_header
based on the configuration that determines the size of hash_digest.
currently it is still all static within crypto.c but as soon as Honza is
done with totemconfig bits, those functions will return the correct size
of the header dynamically.
The whole crypto work is then transparent from totem that will only know
the net_mtu (all it really cares about) to avoid fragmentation.
Cheers
Fabio
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
