Hi Daniel,
I know you were thinking of looking at the MSRP module before the next release, and during discussions here at Crocodile we realised that there was another enhancement that would be useful.
An MSRP relay has the option of splitting large MSRP messages (including those that are already chunked) into smaller chunks. The reason is that there is no maximum size for an MSRP chunk, so it is entirely possible for a client to attempt to send a large file in a single, very-large, MSRP message. In this cases it becomes important to pull the message from the receive buffer in small pieces (instead of waiting for a complete message to arrive and over-flowing the receive buffer) and relaying it in smaller chunks.
Also, the flow control for MSRP is based around TCP windowing, so if you want to limit the rate that someone is sending you MSRP messages (for example during the transfer of a large file) you do so by pulling from the TCP buffer at a lower rate. One way of avoiding overloading an MSRP relay is to have fairly small TCP receive buffers thereby limiting the rate at which clients and relays can send data. However, if the TCP buffers are small the chances of a client sending a message or chunk that is too large (and needs to be chunked by the relay) increases further.
Of course, to do this the MSRP module will need to be able to remember the (From|To)-Path, transaction ID, and so on from the start of the MSRP message so that it can use these (along with calculated Byte-Range) in each additional chunk.
I was thinking a new parameter indicating the maximum MSRP send chunk size is required. If an MSRP message in the receive buffer reaches that number then it has to be pulled from the buffer in parts and relayed as multiple chunks. This maximum send chunk size should be set to be much smaller than the TCP receive buffer size.
Regards,
Peter
Hi Peter,
my plan is to add an internal hash table to keep the details about connections and make routing in the config possible without using htable. This is for next major release, for other things I'm not sure I have time, considering it's very likely to freeze quite soon. If you want to work on it, there should be no conflicts.
Cheers, Daniel
On 12/4/12 6:48 PM, Peter Dunkley wrote:
Hi Daniel,
I know you were thinking of looking at the MSRP module before the next release, and during discussions here at Crocodile we realised that there was another enhancement that would be useful.
An MSRP relay has the option of splitting large MSRP messages (including those that are already chunked) into smaller chunks. The reason is that there is no maximum size for an MSRP chunk, so it is entirely possible for a client to attempt to send a large file in a single, very-large, MSRP message. In this cases it becomes important to pull the message from the receive buffer in small pieces (instead of waiting for a complete message to arrive and over-flowing the receive buffer) and relaying it in smaller chunks.
Also, the flow control for MSRP is based around TCP windowing, so if you want to limit the rate that someone is sending you MSRP messages (for example during the transfer of a large file) you do so by pulling from the TCP buffer at a lower rate. One way of avoiding overloading an MSRP relay is to have fairly small TCP receive buffers thereby limiting the rate at which clients and relays can send data. However, if the TCP buffers are small the chances of a client sending a message or chunk that is too large (and needs to be chunked by the relay) increases further.
Of course, to do this the MSRP module will need to be able to remember the (From|To)-Path, transaction ID, and so on from the start of the MSRP message so that it can use these (along with calculated Byte-Range) in each additional chunk.
I was thinking a new parameter indicating the maximum MSRP send chunk size is required. If an MSRP message in the receive buffer reaches that number then it has to be pulled from the buffer in parts and relayed as multiple chunks. This maximum send chunk size should be set to be much smaller than the TCP receive buffer size.
Regards,
Peter
-- Peter Dunkley Technical Director Crocodile RCS Ltd
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi Daniel,
I won't have time before the freeze either. Any time I do get I plan to spend on outbound support. I may get around to this next year, if no-one ends up needing it sooner than me and does it first.
The Crocodile Javascript MSRP stack behaves a little more nicely than a lot of clients and relays out there. Specifically, it limits the size of chunks it sends and limits the number of chunks that can be outstanding (not received a 200 for) at any time. This means that our client has its own flow control logic designed to avoid overloading the network. Discussions with other people recently has convinced me that other MSRP clients and relays are not always quite as nice and often just throw the data onto the network as quickly as possible. My initial requirement is to use the Kamailio relay with our stack, so re-chunking/flow control is important to me but not yet urgent.
The good news is that, based on discussions I've had with people and testing I've done, I believe that the only two things still required to make Kamailio suitable for large-scale deployment as an MSRP relay is this re-chunking/flow control and failure REPORT generation.
Regards,
Peter
Hi Peter,
my plan is to add an internal hash table to keep the details about connections and make routing in the config possible without using htable. This is for next major release, for other things I'm not sure I have time, considering it's very likely to freeze quite soon. If you want to work on it, there should be no conflicts.
Cheers, Daniel
On 12/4/12 6:48 PM, Peter Dunkley wrote:
Hi Daniel,
I know you were thinking of looking at the MSRP module before the next release, and during discussions here at Crocodile we realised that there was another enhancement that would be useful.
An MSRP relay has the option of splitting large MSRP messages (including those that are already chunked) into smaller chunks. The reason is that there is no maximum size for an MSRP chunk, so it is entirely possible for a client to attempt to send a large file in a single, very-large, MSRP message. In this cases it becomes important to pull the message from the receive buffer in small pieces (instead of waiting for a complete message to arrive and over-flowing the receive buffer) and relaying it in smaller chunks.
Also, the flow control for MSRP is based around TCP windowing, so if you want to limit the rate that someone is sending you MSRP messages (for example during the transfer of a large file) you do so by pulling from the TCP buffer at a lower rate. One way of avoiding overloading an MSRP relay is to have fairly small TCP receive buffers thereby limiting the rate at which clients and relays can send data. However, if the TCP buffers are small the chances of a client sending a message or chunk that is too large (and needs to be chunked by the relay) increases further.
Of course, to do this the MSRP module will need to be able to remember the (From|To)-Path, transaction ID, and so on from the start of the MSRP message so that it can use these (along with calculated Byte-Range) in each additional chunk.
I was thinking a new parameter indicating the maximum MSRP send chunk size is required. If an MSRP message in the receive buffer reaches that number then it has to be pulled from the buffer in parts and relayed as multiple chunks. This maximum send chunk size should be set to be much smaller than the TCP receive buffer size.
Regards,
Peter
-- Peter Dunkley Technical Director Crocodile RCS Ltd
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
-
Daniel-Constantin Mierla -
Peter Dunkley