Set max message payload size from Client class

[ampeixoto]

From what I understand, the field mMaxMessagePayloadSize of WebSocketOptions is used for the maximum size of a message to be sent, while the field mMaxFramePayloadSize is the maximum size of a fragment of the message, in case the message need to be splitted. Is that correct?

If yes, I would like to be able to set mMaxMessagePayloadSize to 16MB and mMaxFramePayloadSize to something much smaller, like 128KB.

But from what I see, when calling the connect() method of the Client class:

I can only pass the mMaxFramePayloadSize in the TransportOptions.

Is there a reason why we cannot pass the mMaxMessagePayloadSize as well?

Am I missing something?

[ampeixoto]

@oberstet Any valuable input from your side? Tested on my side and seems to be working as expected.

[oberstet]

From what I understand, the field mMaxMessagePayloadSize of WebSocketOptions is used for the maximum size of a message to be sent, while the field mMaxFramePayloadSize is the maximum size of a fragment of the message, in case the message need to be splitted. Is that correct?

yes, correct.

If yes, I would like to be able to set mMaxMessagePayloadSize to 16MB and mMaxFramePayloadSize to something much smaller, like 128KB.

yeah, those values make sense and are practical. well, 16MB on mobile networks of course depends .. but in general that should be just fine

Is there a reason why we cannot pass the mMaxMessagePayloadSize as well?

ok, that sounds like it was just accidentally skipped - it should be a tunable knob exposed to users as well. at least that's what I now think without looking into the code;) @om26er what do you think?

[ampeixoto]

yes, correct.

@oberstet I am a bit confused by this then. In our fork, I added the field mMaxMessagePayloadSize to TransportOptions and it seems it works as expected. So, now I have a mMaxFramePayloadSize set to 128KB and a mMaxMessagePayloadSize set to 16MB.

Therefore, I would expect that the maximum bytes per message that could be received in a response to a procedure call would be 16MB, but it seems that as soon as the message received is larger than 128KB, the Exception WebSocketException("frame payload too large") is thrown, causing this client to disconnect.

Shouldn't the message be received anyway as long as the total amount is smaller than 16MB? Am I missing something?

Just to give a bit of context, I am trying to send an image in base64, and it fails if it is a bit bigger (bigger than 128KB). Since we are here, do you have any suggestion on how to send images (or other potential large data) using WAMP?

Thank you for replying!

[om26er]

I agree, that should be configurable and it was an oversight that it isn't today.

Regarding sending large data, my first suggestion would be to use a binary based serializer instead of sending the image as base64. However doing that still doesn't solve the issue where you have a need to send large files. WAMP has a feature called "Progressive calls", however none of the routers out there currently implement that.

In absence of "progressive calls", in one of projects we have made use of an existing feature "progressive call results". We do that by switching roles i.e. the sender registers a procedure that is able to return "progressive call results", then it notifies the receiver to call that procedure.

[ampeixoto]

@om26er Thanks for the reply!

Regarding the configurable mMaxMessagePayloadSize, I get that it was just missed. Clear for me.

What is not so clear is this:
With mMaxMessagePayloadSize set to 16MB and mMaxFramePayloadSize set to 128KB, shouldn't the message be received anyway as long as the total amount is smaller than 16MB?
Because that was what I understood that @oberstet confirmed in his reply. But now that I am looking at this feature "progressive call results", maybe that is only true when using this feature... Am I right?

Also, thanks for your suggestion for handling large data, but I am not sure autobahn-java supports it... It seems only the python and JS clients support it... Is it correct?

[ampeixoto]

@oberstet @om26er Sorry to bother again, but could you please provide some feedback regarding my questions in my previous comment? Thanks!