Closed GoogleCodeExporter closed 8 years ago
Puran:
You are right, it is because of the frame size, the reason is
WebSocketFrameDecoder
for Netty defines the maximum default frame size of 16384 bytes.
and if the client sends the frame size larger than the default max size the
channel
is closed.
Alex
What we should do here is to introduce "multipart tokens". The client checks a
token
if it exceeds a configured maximum size and if so splits it into several parts
(i.e.
the stringified representation of it) that fits into the configured frame size.
Instead of the single huge token we then can send multiple multipart tokens that
simply contain a "value" field which contains a certain part of the already
stringified huge token. The target (either the server if this is the target or
the
client) then can re-construct the token from its several parts and fire the
OnMessage
event not until the entire big token has been completely received.
Original comment by fivefeetfurther@gmail.com
on 28 May 2010 at 12:57
i made the maximum frame size handled by the engine to be configurable. Also
added a method on engine
interface to get the maximum frame size which can be send to the client by
respective plugin.
Original comment by mailtopu...@gmail.com
on 2 Jun 2010 at 11:19
Original comment by fivefeetfurther@gmail.com
on 11 Jun 2010 at 10:27
Original comment by fivefeetfurther@gmail.com
on 11 Jun 2010 at 10:27
this is fixed
Original comment by mailtopu...@gmail.com
on 28 Jun 2010 at 4:43
Original issue reported on code.google.com by
stojadin...@gmail.com
on 24 May 2010 at 10:28