[Help-gnutls] Re: Application Data Spanning Mulitple TLS Records

[Rich Fought]

Hello Simon,

I apologize, my question was actually directed more at the TLS 
specification itself rather than GnuTLS.

I did some research and answered my own question.  The gist of the 
question was: since application
data can be fragmented across multiple TLS records, is there any way to 
tell from the TLS protocol
what records go together to form a single application-level message, 
*without actually looking at the
application data*.

The answer to this question appears to be "no." From the TLS 1.0 RFC:

      struct {
          ContentType type;
          ProtocolVersion version;
          uint16 length;
          opaque fragment[TLSPlaintext.length];
      } TLSPlaintext;

...

  fragment
      The application data. This data is transparent and treated as an
      independent block to be dealt with by the higher level protocol
      specified by the type field.

So one must analyze the application data inside the records to determine 
if a record contains a
single application-level message or a portion of a fragmented 
application-level message.

I was *hoping* that the TLS protocol might have in indication of which 
records go together to
form a single application-level message, much like TCP/IP.  It appears 
that it does not; as such
the thought of a GnuTLS API change is moot.

Regards,
Rich

Simon Josefsson wrote:
> Rich Fought <address@hidden> writes:
>
>   
> > I'm sending large messages greater than 16k over TLS, so I'm having to
> > deal with multiple records.
> >
> > Is there any way in GnuTLS to determine how many records constitute a
> > complete message
> > (perhaps an indicator in the record header, for instance), or is this
> > left to the application layer?
> >     
>
> I'm not sure I understand exactly what you are looking for and why.
> Do you want to find out how many record protocol messages is used for
> some particular application data?  I'm not sure it is easy to extract
> this.  Perhaps Nikos will understand more and answer.
>
> It would help if you could suggest an API that would solve your
> problem, then I can see how difficult it would be to implement that
> API.
>
> Regards,
> Simon
>
>
>
>
>