StompProtocolAndroid icon indicating copy to clipboard operation
StompProtocolAndroid copied to clipboard

Sending Large Payloads

Open afosid opened this issue 5 years ago • 2 comments

Messages which are larger than 8k are now splitted into chunks.

afosid avatar Feb 04 '20 12:02 afosid

The STOMP Specification says, concerning frame size limits:

To prevent malicious clients from exploiting memory allocation in a server, servers MAY place maximum limits on:

  • the number of frame headers allowed in a single frame
  • the maximum length of header lines
  • the maximum size of a frame body

If these limits are exceeded the server SHOULD send the client an ERROR frame and then close the connection.

The spec also says, concerning frame structure:

The frame starts with a command string terminated by an end-of-line (EOL), which consists of an OPTIONAL carriage return (octet 13) followed by a REQUIRED line feed (octet 10). Following the command are zero or more header entries in <key>:<value> format. Each header entry is terminated by an EOL. A blank line (i.e. an extra EOL) indicates the end of the headers and the beginning of the body. The body is then followed by the NULL octet.

In other words:

  1. The STOMP Spec places no limits on frame size. There is no 8k limit on a STOMP frame. That is server-specific, and this generic library cannot enforce your personal configuration, especially at the expense of some other implementations -- which leads me to:

  2. Your code splits STOMP frames up among multiple Websocket frames. This isn't exactly noncompliant with the spec, but it's not specified either. A number of STOMP brokers will allow this behavior, but others will not. So far, this library has made the assumption that 1 STOMP frame = 1 Websocket frame, which is the safest way to go.

So I think that if you want to allow chunking then you need to make the "chunk size" a configurable option in the StompClient, the same way that pathMatcher and legacyWhitespace are configurable there now. It needs to default to 0 or -1, meaning that there is no chunking.

Lastly, the chunking loop needs to be located in AbstractConnectionProvider.send rather than rawSend.

forresthopkinsa avatar Feb 04 '20 22:02 forresthopkinsa

Good idea for splitting messages, but fully agreed with @forresthopkinsa - please make this option configurable and will be better to place chunking into AbstractConnectionProvider

NaikSoftware avatar Jun 25 '20 16:06 NaikSoftware

Ok, thanks for the suggestions.

afosid avatar Jan 09 '23 20:01 afosid