Nikos Mavrogiannopoulos nmav at
Sat Aug 2 10:31:34 CEST 2008

Sebastien Decugis wrote:

> In its current state, the gnutls library misses the ability to have
> several gnutls_session_t associated to a single connection object. It is

I depends on how you define the object. You can associate each session
with a transport pointer, which can be anything you like and will be
passed to push/pull functions and also a custom pointer which can be
anything you like and is available to you only.

> a problem on message reception, because we can determine the session to
> which a message belongs only *after* we receive it. This demultiplexing
> operation is not currently allowed in gnutls, AFAIU.

A layer that would demultiplex the streams before should be needed.
That's correct.

> I am considering to implement such support in the gnutls library, either
> as a new session object ("gnutls_session_multistream_t") or as an
> extension of the current session object (adding new fields to it).
> Basically, the differences are:
> -> ability to define a number of independent communication channels
> (bi-directional streams) in the object.
> -> storage for this same number of sessions states (the current
> gnutls_session_t)
> -> different prototype of the push and pull transport callbacks, that
> take an additional parameter (the stream id on which to send / on which
> the message was received)

Can't this be achieved by having a layer of demultiplexing before gnutls
that will use separate pull/push functions and a custom transport
pointer? That we could include in gnutls as helper functions for SCTP.


More information about the Gnutls-devel mailing list