Re: [PATCH 4/6] sctp multistream scheduling: extend socket API

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Yaogong Wang
Date: Saturday, June 5, 2010 - 12:40 pm

On Thu, Jun 3, 2010 at 8:24 AM, Vlad Yasevich <vladislav.yasevich@hp.com> wrote:

There is an important design issue here: when should the user set this
socket option?

My current assumption is that the user choose the scheduling algorithm
after declaring the socket but before the establishment of any
association. Therefore, the granularity of control is socket-based
rather than association-based. In one-to-many style socket case, all
associations inherit the scheduling algorithm of the socket. The
problems with this approach are:
1. Cannot specify different scheduling algorithm for each association
under the same socket
2. Since the option is set before the establishment of any
association, it doesn't know how many streams would be negotiated. It
could only consult initmsg for the intended number of outgoing
streams.

If we go with the association-based approach, the above problems can
be solved. But the question is: in this case, when should the user set
this option? In one-to-many style socket, associations are implicitly
established. There isn't a point where association is established but
data transfer hasn't started yet so that the user can choose the
scheduling algorithm. Any suggestion on this dilemma?




-- 
========================
Yaogong Wang, PhD candidate
Department of Computer Science
North Carolina State University
http://www4.ncsu.edu/~ywang15/
========================
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [PATCH 4/6] sctp multistream scheduling: extend socket API, Yaogong Wang, (Sat Jun 5, 12:40 pm)