ag at ag-projects.com
Sun Dec 11 14:36:42 CET 2011
If that's the meaning, one TCP connection could theoretically be reused to multiplex multiple MSRP session between the same targets.
But if you would reuse same TCP connection, then one single file transfer session could potentially monopolize it preventing smaller chat messages to be delivered in a timely manner before the transfer is finished. It is much easier to apply throttling policies in a router or relay on a per TCP connection basis, to prioritize chat sessions against file transfer session for instance, doing it inside the protocol would add a lot of overhead and extra processing in all end-points.
In Blink every new MSRP session establishes a new TCP connection. Also MSRPRelay does not reuse TCP connections for the reason mentioned above.
On Dec 11, 2011, at 1:44 PM, Olaf Monien wrote:
> As far as I know TCP stitching is not mentioned in any related RFC, but it is a term rarely used to describe a protocol's feature that may allow TCP packets from more than one connection to be combined - "stitched"
> Grüße / Regards,
> Olaf Monien
> Sent from my iPad
> Am 11.12.2011 um 07:15 schrieb Adrian Georgescu <ag at ag-projects.com>:
>> Personally I have never heard about such thing. Where have you learned about this?
>> On Dec 11, 2011, at 8:57 AM, Varun Agrawal wrote:
>>> Hi All,
>>> what is the difference between MSRP:( tcp stitched and non-stitched) session.
>>> Varun Agrawal | Test Engineer| GlobalLogic Inc.
>>> Leaders in Software R&D Services
>>> ARGENTINA | CHILE | CHINA | GERMANY | INDIA | ISRAEL | UKRAINE | UK | USA
>>> B-34/1, Sector 59, Noida 201301 U.P. India
>>> Office: <4213> | Mobile +91 99111 72990
>>> Blog: blogs.globallogic.com
>>> Blink mailing list
>>> Blink at lists.ag-projects.com
>> Blink mailing list
>> Blink at lists.ag-projects.com
> Blink mailing list
> Blink at lists.ag-projects.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Blink