But before decoding, you will not know where is the Content-Length and its value. Based on double CRLF, we can know that the message header is finished but where is the end of the whole message? -----Original Message----- From: Matthew Gardiner [mailto:[EMAIL PROTECTED] Sent: 2006年2月6日 16:47 To: 'Rocky Wang'; 'SIP Implementors' Subject: RE: [Sip-implementors] SIP over TCP implementation
I believe that SIP messages are terminated by 2 line-ends, whereas SIP messages carrying one or more message bodies indicate the length of their attached cargo by means of the Content-Length header. These facts are adequate for receive logic to determine the end of a message. Matt -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Rocky Wang Sent: 06 February 2006 07:05 To: 'SIP Implementors' Subject: [Sip-implementors] SIP over TCP implementation Hi, I have one question with respect to SIP over TCP implementation. Because the TCP connectsion provides stream service, after gets some bytes from the stream, how a SIP node knows when a SIP messages is finished receiving, or more fragments are still in the data stream? The receiver must try to do the decode the received fragments as supposing the SIP message is completed. If decoding failed, then wait for more bytes from the stream and do a next decoding again. If the receiver must do the docode again and again, it will cost a lot of CPU time slot, I think. Do you have any good idea to improve or resolve the problem. Best Regards, Rocky Wang _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
