You should never assume that all of your data is available. If you work with this, you can handle any speed client. I test everything against simulated invalid packets and random latency. On Nov 25, 2013 9:38 AM, "Andrew Pennebaker" <[email protected]> wrote:
> This is a good edge case to consider, as some script kiddy tools for > attacking websites behave this way. > > > On Fri, Nov 22, 2013 at 4:00 PM, Binole, Bill < > [email protected]> wrote: > > > I was wondering how to handle a slow client. So say my client writes 100 > > bytes and then 5 seconds later writes another 100 bytes. What is being > > sent is delimited with a start and end block that I am checking for to > > insure I have a full message. I have written a decoder based on the > > CumulativeProtocolDecoder that works just fine except for the case of a > > slow client. In this case the buffer is drained before the end block is > > received and it is causing a bogus error condition. Is there a way to > > handle this within the decoder? > > > > Bill > > > > ______________________________________________________________________ > > The contents of this message, together with any attachments, are intended > > only for the use of the person(s) to which they are addressed and may > > contain confidential and/or privileged information. Further, any medical > > information herein is confidential and protected by law. It is unlawful > for > > unauthorized persons to use, review, copy, disclose, or disseminate > > confidential medical information. If you are not the intended recipient, > > immediately advise the sender and delete this message and any > attachments. > > Any distribution, or copying of this message, or any attachment, is > > prohibited. > > > > > -- > Cheers, > > Andrew Pennebaker > [email protected] >
