Subject: Re: [Tsvwg] sctpsocket: Returning unsent messages

From: Jonathan Wood <[email-masked]>
Date: Mon, 25 Jun 2001 22:29:35 -0700 (PDT)

Actually, unsent retrieval is no longer via ancillary data. The
latest TSVWG draft has the right semantics and is considerably
better WRT to the problems you've pointed out (although there
is still room for tightening it up, I'll admit).

There are still a few places that we missed in the cleanup, and
it's still referred to as ancillary data, but these should be
all fixed in the -01 version, to appear soon. Mike Bartlett
pointed out a number of these.

> 
> Well, that would indicate the three situations; however, I don't totally
> agree with section 5.3.1.4 anyway.  There isn't much point for an
> ssf_type when there is a type in the cmsg structure.  There isn't much
> point for a ssf_length field when there is already a length in the
> cmsg structure which spans the entire ancillary data.  No point for
> an ssf_error field (which has no defined values).  UNIX error codes
> should suffice.  The ssf_data field is heavily underdefined.  Does this
> contain the data sent by the user?  What part of it?  The part that
> was sent in a fragment and absorbed in the sendmsg call?  The part
> that was sent and acknowledged after SCTP fragmented it?  The part
> that was sent by SCTP after SCTP unfragmented it?  An entire MTU
> of data?  The entire data (TSDU)? (could be big).  What about truncation
> of cmsg data on recvmsg?
> 
> I agree with the principle, but the syntax and semantics needs a lot
> of work.
> 

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Tue, 26 Jun 2001 09:05:33 -0500

Jonathan:

Yes, I was going to point this out... a lot of these
messages are NOT in ancillary data. The reason
being that, as you illustrated earlier, ancillary data
does not do well with variable length structures.

I had noticed in a hurried read of -00 last week that
we missed a few places where the ancillary data t

Rerm
was left hanging.. We need to go carefully through
the draft and emphasis where and where not the structures
show up as ancillary data...

We will definetly get this one fixed in the next pass though :)

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)