-1

I've been reviewing Websockets messaging protocols. Looking at WAMP, it has the basic features I want. But in reading the docs, it appears that it requires a messages to route through the broker. Is this correct?

I am looking for real time messaging. While the broker role may be useful as a means of bringing together the publishers and subscribers, I would want the broker to only negotiate the connection, then hand-off sockets/IPs to the parties - allowing direct routing between the involved parties without requiring the broker to manage all the real time messaging. Can WAMP do this?

Emile Cormier
  • 28,391
  • 15
  • 94
  • 122
Troy Harvey
  • 1,365
  • 2
  • 13
  • 24

1 Answers1

1

Two WebSocket clients (e.g. browsers) cannot talk directly to each other. So there will be an intermediary involved in any case.

WAMP is for real-time messaging. To be precise, WebSocket is for soft real-time. There are no hard real-time guarantees in any TCP based protocol running over networks.

Regarding publish & subscribe: a broker is always required, since it is exactly this part which decouples publishers and subscribers. If publisher would be directly connected to subscribers (not possible with 2 WebSocket client anyway, but ..), then you would introduce coupling. But decoupling a main point of doing PubSub anyway.

What exactly is your concern with having a broker (PubSub) or a dealer (RPC) being involved? Latency?

oberstet
  • 21,353
  • 10
  • 64
  • 97
  • I've got application where there are two scenarios: 1) where there is a local server/dBase for which there are many clients. Each action by every client that changes the dBase triggers a sync method that updates all clients through messaging. In this case the local server is also the router, and the model isn't a problem (i think?) 2) Where there is a global cloud server that gets a ping from all the local servers. A client can log on to the cloud server and get a socket hand-off to any local server/router. This is the case that concerned about. – Troy Harvey Mar 21 '14 at 04:09
  • If I understand correctly, in case 2) you'd just get the address of the local server on the initial connection, then close the initial connection and connect to the local server. AFAIK there's no way to hand over an existing connection, so you'd need to reconnect anyway. The above is perfectly possible using WAMP. – gzost Mar 21 '14 at 10:05
  • 1) right, no problem. 2) what is a "socket handoff"? TCP does not provide mechanisms to handover an established connection to another IP. What you can have is what @gzost describes: client connects to cloud server which hands out new IP for reconnecting to "local server". – oberstet Mar 21 '14 at 23:13
  • Socket-handoff was my shorthand for saying that the clouds only job is to keep a directory of IPs pinging the cloud server. If it knows IPs of both A and B, it can exchange their information, so that a direct connection can be made. In my case, I can't see a lot of value in having to funnel all info through single router... unless I'm not seeing something fundamental – Troy Harvey Apr 09 '14 at 03:32
  • The advantage of using a router is that it works. As said, two browsers simply cannot connect directly and talk WebSocket. – oberstet Apr 10 '14 at 08:26