[PULL][PATCH] Small buffering fixes, start of recv side cleanup

[Nikos Mavrogiannopoulos]

On 09/01/2010 02:32 AM, Jonathan Bastien-Filiatrault wrote:

>> Hi and thank you! My question would be how would you move on. That is
>> what would be your next (planned) moves in adding DTLS?
> 
> My pleasure,
> 
> I am currently working on getting GnuTLS to receive datagram-sized
> chunks and adapting the record layer so that records cannot span
> datagrams when using DTLS.
> 
> Towards that goal, I have forward-ported my old (1 year+) patches to the
> current master branch.
> My current progress is here (broken code warning in full effect):
> http://github.com/jothan/gnutls/commits/rebase%2Fdtls/
> The handshake buffering code in those patches needs to be completely
> redone.

Pretty fair.

> The next steps are the recv + record side work I mentionned above. After
> that, I will need to add HelloVerifyRequest processing. At that point, I
> should be very close to (drum roll...) achieving the first
> inter-implementation Free Software DTLS handshake between OpenSSL and
> GnuTLS.

That would be nice :)

> Many issues regarding timeout and retransmission issues are yet to be
> solved. The division of responsibilities between the application and the
> library regarding those issues are pretty much still in the air.

I'd suggest to move everything to the layer over gnutls. As far as I
understand from DTLS is that it can be used over many unreliable layers
with different characteristics. Maybe some sensible "defaults" exist for
UDP, as we do now for TCP.

> Regarding the patches, would it help you and Simon if I mail patches
> series individually instead or in addition to requesting a git-pull ? It
> might more accessible to others for comment and review.

At least for me patches are easier reviewed by e-mail. However I think
it might be better to send patches (at least for merging) once some
milestones you set are completed (say once DTLS datagrams can be sent
and received, handshake works etc). That way you'll be free to change
anything in your previous work, without fearing touching already
submitted code. The current master code that you are working on
shouldn't change in this aspect. Looking forward for your patches! :)

best regards,
Nikos