[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-19.txt

Rémi Denis-Courmont wrote:

On Monday 08 December 2008 10:25:52 ext Christian Haas, you wrote:
Requests always need to be serialized when using TCP, since we have only one "channel". You can pipeline outgoing requests without waiting for the response to the previous one. 
But only regarding one session.
The current spec requires that responses come in the same order as requests (section 12): 

   (...) For RTSP where the relative order of requests will
   matter it is important to maintain the order of the requests.
   Because of this the the responding entity SHALL process the incoming
   requests in their sending order.  The sending order can be determined
   by the CSeq header and its sequence number.  For TCP the delivery
   order will be the same as the sending order.  The processing of the
   request SHALL also have been finished before processing the next
   request from the same entity.  The responses MUST be sent in the
   order the requests was processed.
...is "the same entity" meaning the client or the state machine that handles one session? If it is the client, then setting up 20 sessions with each requiring 5 seconds on the server to be set up will have the 20th prepared after 20*5 seconds. And only after that time, the first session will be available for some further control again.
I agree that CSeq would be useful, and even necessary, if response were not ordered. But they _are_ ordered, and hence CSeq is _useless_.
If you want a reference number, you can maintain a counter of request sent, and a counter of response received, and match them. As it happens, these counters will be equal to CSeq, except that you don't need to exchange them over the wire.
I would be very much against allowing disordered response, as it introduces horrible race condition in the protocol state machine: client and server must agree on the order of processing the requests.
I agree with you that requests /regarding one RTSP session/ need to be in strict order, but I don't see a reason to impose this order down to the control connection. All I want and need is to control several sessions in parallel (and I don't only mean SETUP, all other methods as well) -- those regarding one session need to be ordered of course (serialized, always awaiting the response of the previous). 



In some of our cases having the client open up a dedicated TCP
connection per RTSP session is not an option (the client being a small
embedded host). By the way, this would then also nullify the reason for
having session identifiers at all.
Connection pooling does not require CSeq to work. And anyway, session identifiers are needed to switch control connection, for instance during a hand-over.
I understand that for pooling CSeq isn't required, but it makes life (implementation) a bit easier, as described in the other mail. Personally, I wouldn't have that much problems without a CSeq (as I'm the server implementor), but I guess that some clients [of mine] might resort to abuse the first Timestamp field (which the server needs to mirror, like the CSeq). Assuming parallel control of sessions is allowed, reading message traces is a bit easier with simple sequence numbers than with complex session identifier. Though I have to admit, this is a mood point.
But apart from the form of referencing requests/responses to sessions, what about SET_PARAMETER and GET_PARAMETER, which are not required to be bound to a session and might only operate on given resources 'globally'? I'd also like to be able to control two or more different resources in parallel, having one operation not to wait for the completion of an operation on another resource. Without CSeq nor a Session, how can these responses be matched to the original request? If these transactions need to be strictly ordered as well, then RTSP is going to be very unpractical for two agents communicating about more than one resources/sessions. 

Regards,
ch

_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic