[twitter-dev] stream heartbeat/keep-alives
the twitter streaming api docs say Parsers must be tolerant of occasional extra newline characters placed between statuses. These characters are placed as periodic keep-alive messages, should the stream of statuses temporarily pause. These keep-alives allow clients and NAT firewalls to determine that the connection is indeed still valid during low volume periods. that's all well and good, but I'd like some clarification on some behavior I'm seeing. I never see newlines come through alone... rather I always see CRLF (carriage return + linefeed; adjacent) pairs (two chars) come through on 30 second intervals to keep-alive. as a result, I've built my parser to consider the combination CRLF as the heartbeat. should I be doing this, or am I missing something along the way in which I should truly only ever be looking for LFs? To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] stream heartbeat/keep-alives
CRLF pairs are indeed what get sent, and what you should build around. You shouldn't ever get a naked LF. ---Mark http://twitter.com/mccv On Fri, Mar 19, 2010 at 3:50 PM, Jud jvale...@gmail.com wrote: the twitter streaming api docs say Parsers must be tolerant of occasional extra newline characters placed between statuses. These characters are placed as periodic keep-alive messages, should the stream of statuses temporarily pause. These keep-alives allow clients and NAT firewalls to determine that the connection is indeed still valid during low volume periods. that's all well and good, but I'd like some clarification on some behavior I'm seeing. I never see newlines come through alone... rather I always see CRLF (carriage return + linefeed; adjacent) pairs (two chars) come through on 30 second intervals to keep-alive. as a result, I've built my parser to consider the combination CRLF as the heartbeat. should I be doing this, or am I missing something along the way in which I should truly only ever be looking for LFs? To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] stream heartbeat/keep-alives
Newline is a logical concept generally materialized as a CRLF. The pair of characters is a newline. Generally you don't need to look for the newline, if you can set your TCP socket timeout to some small multiple of the keepalive time, perhaps 60 or 90 seconds, you should get this for free. -John Kalucki http://twitter.com/jkalucki Infrastructure, Twitter Inc. On Fri, Mar 19, 2010 at 3:50 PM, Jud jvale...@gmail.com wrote: the twitter streaming api docs say Parsers must be tolerant of occasional extra newline characters placed between statuses. These characters are placed as periodic keep-alive messages, should the stream of statuses temporarily pause. These keep-alives allow clients and NAT firewalls to determine that the connection is indeed still valid during low volume periods. that's all well and good, but I'd like some clarification on some behavior I'm seeing. I never see newlines come through alone... rather I always see CRLF (carriage return + linefeed; adjacent) pairs (two chars) come through on 30 second intervals to keep-alive. as a result, I've built my parser to consider the combination CRLF as the heartbeat. should I be doing this, or am I missing something along the way in which I should truly only ever be looking for LFs? To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
