thanks for the link, it’s a quite interesting limitation of WebSockets I was not aware of and a nice proposal, BTW!
However, I am pretty sure the problem I am trying to bring your attention to is different.
Let me show you an example.
I’ve created an Autobahn|Cpp Server (Callee) based on “register1” example and added an empty “acceptArray” function there. Also, I’ve created two Autobahn|JS web clients (Callers), one calling standard “add2” function (CallerAdd) and another one (CallerArray) sending an array of 4M elements over to the “acceptArray” function on the server. Obviously, I used Crossbar.io as a router.
I got Crossbar and the Server running and checked that CallerAdd sends its requests correctly. Then I started CallerArray client that initiated transferring 4M elements. While the latter request was running (~25s), I tried sending requests from CallerAdd again - none of them was processed before the Crossbar.io finished transferring data to the Server. As you see, just one call from one client can block the entire system completely so none of other clients are able to use the server.
To the contrary, a raw zaphoyd/websocketpp -based WebSocket server works quite differently in the same scenario. While the server is receiving a big array from one client, it readily processes smaller requests from other clients.
With these experiments run, I think that the aforementioned WebSocket protocol’s limitation is not the origin of the problem I am describing, but rather the fact that there is only one socket/transport in between Router and Callee is. It appears that the situation could be greatly improved if WAMP would create one Router-Callee socket per every Caller-Callee pair or at least a pool of sockets. Unless I miss something important, I can’t see how the current WAMP implementation can be used for the purposes I have in my mind.
Do you consider addressing this issue in the future?
On Monday, March 2, 2015 at 8:21:39 AM UTC-8, Tobias Oberstein wrote:
Am 02.03.2015 um 17:09 schrieb Ivan Komarov:
What I have in mind, is a situation when frequent lighweight requests
are mixed with rare heavy ones and I don’t want to see the latter ones
completely blocking processing the formers.
Ah, so you a concerned about so called “head of line blocking” at the
(single) transport level.
A single, standard WebSocket transport can’t interleave messages. Once
message has started to be sent out / or received, everything for that
message needs to go over the transport first.
This isn’t specific to WAMP, but standard WebSocket.
Extensions to WebSocket could. See my proposal addressing exactly this
Note that WebSocket MUX and HTTP/2 have multiplexing of multiple
connections over a single physical connection (TCP), but they don’t
directly address interleaving messages (allowing for priorization and
avoiding head-of-line blocking on a single channel).