John,

Thank you for getting back to me.

The doc lists a "For example, reconnect no more than twice every four 
minutes, or three times per six minutes, or some similar metric." but 
doesn't give a "Don't reconnect more than a few times a minute unless you 
are retrying automatically due to failures, but remember to use exponential 
backoff to a reasonable upper limit depending on the type of failure." ;)

(also, mistype earlier: "nor does it get connected by the server" should 
have read "nor does it get disconnected by the server")

The funny thing is, I've actually discarded the client that I was using, and 
have written one from scratch using Python's asynchronous sockets. Every 
other time I've written async socket clients/servers, when a connection is 
closed, the socket will be seen as "readable" but when read will return zero 
bytes; this is a semantic that has worked for me every other time in the 
past, is the standard behavior for countless async (and sync libraries), and 
is the most reliable cross-platform way to detect socket disconnect. 
Worst-case scenario, the socket will come up as being in an error condition 
(I handle that too, but it hasn't come up when connecting to 
stream.twitter.com). Looking at a wireshark dump, I see some sort of 
disconnect-like packet, but the socket is never seen as readable or in an 
error condition according to select (Python wraps the standard system 
routines), and both lsof AND netstat see the sockets as being "established" 
(as opposed to disconnected, time_wait, etc.)

I have worked around the seeming lack of connect, I was just reporting what 
I was experiencing.

Regards,
 - Josiah

On Sunday, February 27, 2011 9:56:04 PM UTC-8, John Kalucki wrote:
>
> This is documented in painful detail here: 
> http://dev.twitter.com/pages/streaming_api_concepts#updating-filter-predicates
> .
>
> If you connect a second time, you should get a TCP Close or Reset on the 
> first connection. It sounds like your client library isn't detecting the 
> connection close.
>
> -John Kalucki
> http://twitter.com/jkalucki
> Twitter, Inc.
>
>
> On Thu, Feb 24, 2011 at 1:08 PM, Josiah Carlson <josiah....@gmail.com>wrote:
>
>> Now that I've got OAuth with statuses/follow.json working, I've been 
>> working through building a small part of our app.
>>
>> Part of the streaming API docs state that only one connection is allowed 
>> (reasonable). Upon making a second connection, the first no longer receives 
>> any data (not even anti-timeout newlines), nor does it get connected by the 
>> server. On my end of things, I've written an async client which can detect 
>> such a condition (it watches a shared Redis key looking for a changed state 
>> when it doesn't receive any data for a while), and automatically 
>> disconnects.
>>
>> The streaming API docs also state that repeated reconnections, etc., are 
>> frowned upon and may result in banning.
>>
>> My question is simple: how often can I reconnect to follow different 
>> people/keywords? Obviously ten times a second is well beyond reasonable and 
>> would probably get us banned in seconds. But isat most once every 5 minutes 
>> okay? At most once every minute? At what level would we be safe?
>>
>> Thank you,
>>  - Josiah
>>
>>  -- 
>> Twitter developer documentation and resources: http://dev.twitter.com/doc
>> API updates via Twitter: http://twitter.com/twitterapi
>> Issues/Enhancements Tracker: 
>> http://code.google.com/p/twitter-api/issues/list
>> Change your membership to this group: 
>> http://groups.google.com/group/twitter-development-talk
>>
>
>

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Reply via email to