On Feb 19, 2:55 pm, John Kalucki <j...@twitter.com> wrote: > This shouldn't be happening, and having developers build these sorts of > workarounds saddens me. > > It is possible that the server side is holding dead connections open, but I > doubt it -- as I've a considerable amount of data to the contrary. I suspect > that the socket code does not detect a close, driven by either a TCP Close > or a TCP Reset. I've run connections over the public internet with close > monitoring and rarely noticed a timeout. > > If you point the same client at a file of streaming data on a web server, > does the client detect the end of file at the correct point? > > -John Kaluckihttp://twitter.com/jkalucki > Infrastructure, Twitter Inc.
Yeah ... I think we're stuck with this sort of thing until we get a robust library in portable *C* code. I took a look at the one from Gist that's noted on the web site - it's in Java, but I don't see why it couldn't be ported to C and released in open source. I don't want a Java Virtual Machine dependency just to talk to Streaming, though. ;-) You really only need to do the connection stuff in C - using SWIG, you can link to any higher-level language for feeding to a queue, flat file, RDBMS, NoSQL database, etc. Any chance libcurl could do this? There are already libcurl bindings for most of the languages, and there are Windows binaries. Could Twitter write and publish something? I'd think the time saved from not having to chase down Streaming connection problems would more than pay for the effort.