I want to write a client for a protocol where the server sends length-prefixed data. The data requires nontrivial decoding and processing, and at any moment the client only needs the latest available data: if there is more data available, it's desirable to flush the old entries and use only the newest one. This is to avoid situations where the client spends so much time processing data that it starts getting more and more behind the server.
I can easily implement reading the length-prefixed data with twisted.protocols.basic.IntNStringReceiver, but how would I check if there is more data available? What I would perhaps like to do is call select on the socket with a zero timeout to see if reading from the socket would block, and if not I'd just skip all decoding and processing. The socket is of course not available in the Protocol.dataReceived method call. Another idea would be to store the data somewhere and start a delay, and if the method is called again before the delay fires, overwrite the data. This imposes a constant delay even in the usual case where there is no more data available. Is there some way to do this that would fit well the Twisted programming model?
There aren't any peek-ahead APIs in Twisted that will let you know if there is data waiting in a buffer somewhere that's about to be delivered.
I think your second idea is just fine - as long as you notice that you can pick an arbitrarily small constant delay.  For example, you could pick 0 seconds.  In practice this introduces a slightly longer delay (unless you have a really fast computer ;) but it's still small enough that you probably won't notice it.
It's possibly also worth knowing that Twisted reactors try to interleave processing of time-based events with processing of file descriptor-based events.  If you didn't know this then you might suspect that using reactor.callLater(0, f) would call f before any more I/O happens.  While there's no guarantee of exactly how events are ordered, all of the reactors that ship with Twisted just go back and forth: process all I/O events, process all time events, repeat.
And if you pick only a slightly larger value, perhaps 1/10th of 1 millisecond, then you can pretty much be sure that if dataReceived isn't called again before the timer expires there isn't any more locally received data that is about to be delivered to your application.
Skipping stale data in a Twisted protocol handler