3

I am trying to create a network architecture which has a single server and multiple clients. The clients can connect and disconnect at any time so they need to announce their existence or shut-down to the server. The server must be able to send data to any particular client.

What is the best scalability protocols/architecture to use for this?

Currently I use a REQ/REP so that clients can 'login' and 'logout', and a SURVEY socket so that the server can send data to all clients. The message sent has an ID for the particular client it wants to process the message.

Is this good, or is there something better?

user3666197
  • 1
  • 6
  • 50
  • 92
Cthutu
  • 8,713
  • 7
  • 33
  • 49

2 Answers2

2

Sounds more like you need publisher subscriber. With both 0MQ and nanomsg you don't need to do anything in particular to manage connection / disconnection, the library does that for you.

However if you want more sophisticated message management (such as caching outgoing messages just in case another client chooses to connect) then you will have to manage that yourself. You might use a single push pull from the clients for them to announce their presence (they'd send a message saying who they were), followed by more push pulls from the server to each of the clients to send the messages from the cache that you have. Fiddly, but still a whole lot easier than programming up with raw sockets.

Using req rep can be problematic - if either end crashes or unexpectedly disconnects the other can be left in a stalled, unrecoverable state.

bazza
  • 7,580
  • 15
  • 22
  • 1
    Thanks for the helpful reply. I still have a question about pub/sub that I asked above, but I will repeat it here for convenience: Isn't a PUB/SUB one-way? So it would solve the issue with the server sending clients data, but how would the client 'announce' itself to the server using the same socket? Would that require another socket? – Cthutu Sep 23 '15 at 13:13
  • 2
    @Cthutu, pub sub is indeed one way. But you're not limited to a single pattern between a client and a server. You can have a push pull going back the other way too. You've not said exactly what messaging behaviour you want - you might not need even that. The clients can use that to say that they're there. It helps a lot to stop thinking of clients / servers, and start thinking of communicating peers. – bazza Sep 23 '15 at 14:34
  • I thought I did describe what I wanted in the question. I'll try to describe again as I probably wasn't clear enough. The server sends data (that it produces) to the clients for processing (one-way), and clients announce to the server when they connect and disconnect. Maybe clients don't need to announce themselves with pub/sub and it's done automatically with nanomsg? – Cthutu Sep 23 '15 at 14:46
  • 1
    @Cthutu, well you've said "login logout" and "survey so that the server can send to all clients". You've not said why you need login / logout. 0MQ and nanomsg both seemlessly manage connection / disconnection unseen in the background. If all you want is for the clients to get the next message after they connect, just use pub/sub. 0MQ and nanomsg will automatically connect subscribers when they create their sub socket, the pub doesn't have to do anything. "Login / logout" hints at a more complex requirement than that, which could be satisfied by adding in some push pulls too. – bazza Sep 23 '15 at 15:40
2

Sorry, in real world, there is no "One Size Fits All"

There are many further aspects, that influence architecture - The Bigger Picture.

While both Martin SUSTRIK's cool kids -- ZeroMQ & nanomsg -- have made a gread help in providing excellend bases + LEGO-type building blocks of Scaleable Formal Communication Patterns, they are only the beginning and saying that REQ/REP or SURVEY Behavioural Primitives ( great innovation, nevertheless still a building block ) are The Architecture would get upset almost all architects and evangelists.

The original question is important, however you already have gotten a first proposal to get it administratively closed as some people with "wider wingspan" feel your question is "too wide" or "opinion"-oriented instead an MCVE code-example driven ( ... yes, StackOverflow life is sometimes fast and cruel ).

So, without any further details available, my recommendation would be to check recent versions of PUB/SUB ( which can and do filter on PUB-side ( not on the SUB as was the design in the early ZeroMQ versions, once already xmited / delivered zillions of bytes round the world to just realise on the globally distributed peers level that no-one has yet SUB-ed to receive anything of that ) instead of the mentioned SURVEY.

Without any context it is nonsense to seriously judge, the less to improve what you try to design and implement.

I would do a poor service I were trying to do so.

The best next step?

What I can do for you right now is to direct you to see a bigger picture on this subject >>> with more arguments, a simple signalling-plane / messaging-plane illustration and a direct link to a must-read book from Pieter HINTJENS.

Community
  • 1
  • 1
user3666197
  • 1
  • 6
  • 50
  • 92
  • Thanks for the reply. Isn't a PUB/SUB one-way? So it would solve the issue with the server sending clients data, but how would the client 'announce' itself to the server using the same socket? Would that require another socket? – Cthutu Sep 23 '15 at 13:12
  • Oh sure it is. New implementation of PUB/SUB brings unparalleled efficiency of *broadcast* 1:all without imposing pattern-obligation to *respond*. All the other features, the more their efficient implementations, deserve a parallel signalling constructs ( FSA-of-FSAs in principle ), so do not try to stick to trying to match a "super-pattern" to a single primitive DEALER/ROUTER, XREQ/XREP et al. use coordinated efforts of several of these, orchestrated according to your analysed needs within your solution architecture. Enjoy these cool non-blocking powers. – user3666197 Sep 24 '15 at 19:06