Shelby Ramsey <sicfsl...@gmail.com> writes: > The events have a Content-Length: \d+ as the protocol for determining the > length of the message. What I'm struggling with is how to parse that and > then receive just that length as an individual message ...
It would probably help to see the general framework of your server class to be more specific, but in general, try implementing a LineReceiver protocol that starts in line mode and then switches to raw mode after receiving the event header, switching back after receiving the appropriate amount of raw information. You don't mention if the Content-Length header ends with a CRLF or not, but if it doesn't and you have control of the protocol, I'd suggest making it do so. If you can't control that you'll have to do your own protocol to identify when the header is actually done - using LineReceiver as a model would probably be helpful. Here's an old post of mine showing something an approach I use in one of my applications that receives a binary file after a short header with some identification and length information. http://www.twistedmatrix.com/pipermail/twisted-python/2007-July/015738.html You'll have some additional complexity in that you will have to manually observe the transition between any final raw data from the last event and the beginning of the next event. But that's not too bad - just identify when your remaining raw bytes hits zero, and anything else you have left in that callback is for the subsequent event. Luckily, Twisted's LineReceiver also anticipated this use case. When your raw data receiver switches back to line mode with setLineMode, you can pass in the extra data, and it will automatically be reparsed, calling lineReceived() if appropriate or else holding on for the rest of the upcoming event header. -- David _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
