zmq: quando utilizzare zmq_bind o zmq_connect

Question

Refer to http://hintjens.wdfiles.com/local--files/main:files/cc1pe.pdf 
Page 22 Chapter Divide and Conquer 

        Ventilator[PUSH] 
     ___________________|____________________    
     |     |     | 
[PULL]Worker[PUSH] [PULL]Worker[PUSH] [PULL]Worker[PUSH] 
     |__________________|___________________|    
          |     
        [PULL]Sink 

// taskvent.c 
    // Socket to send messages on 
    void *context = zmq_ctx_new(); 
    void *sender = zmq_socket (context, ZMQ_PUSH); 
    zmq_bind (sender, "tcp://*:5557"); 

    // Socket to send start of batch message on 
    void *sink = zmq_socket (context, ZMQ_PUSH); 
    zmq_connect (sink, "tcp://localhost:5558"); 

// taskwork.c 
    // Socket to receive messages on 
    void *context = zmq_ctx_new(); 
    void *receiver = zmq_socket (context, ZMQ_PULL); 
    zmq_connect (receiver, "tcp://localhost:5557"); 

    // Socket to send messages to 
    void *sender = zmq_socket (context, ZMQ_PUSH); 
    zmq_connect (sender, "tcp://localhost:5558"); 

// tasksink.c 
    // Prepare our context and socket 
    void *context = zmq_ctx_new(); 
    void *receiver = zmq_socket (context, ZMQ_PULL); 
    zmq_bind (receiver, "tcp://*:5558"); 

I feel confused when to use zmq_bind or zmq_connect. 
It says that most of time "Server" uses zmq_bind and "Client" uses zmq_connect. 

Question> When I should use zmq_bind and when I should I use zmq_connect? 

http://api.zeromq.org/ 
zmq_bind - accept incoming connections on a socket 
zmq_connect - create outgoing connection from socket 

Answer 1

Esistono alcuni principi di base per il collegamento e il collegamento. In generale, zeromq non si preoccupa *, dipende solo da te ciò che è più conveniente.

Per una data coppia di socket che parlare gli uni agli altri, ecco un paio di domande da porre per capire che deve legare, e che dovrebbe collegare:

1. Does uno dei processi di vivere più a lungo l'altro (cioè si avvia, si fa qualcosa, si ferma, mentre l'altro si siede e corre a lungo)? Se è così, il più longevo dovrebbe legarsi.
2. Avete più istanze di un lato o dell'altro? In tal caso, quello che non è multiplo (o quello con meno istanze) dovrebbe essere associato, poiché questo è un numero inferiore di URL da tenere sotto controllo.

Questi sono principalmente per rendere più facile la gestione di URL e connessioni. Nell'esempio di ventilazione/affondamento, c'è esattamente un ventilatore e un lavandino, ma può esserci un numero qualsiasi di lavoratori (zero-a-molti). Se il lavandino e lo sfiato si legano entrambi, allora non hanno bisogno di sapere degli operai quando vanno e vengono. Ci sono solo due URL da tenere sotto controllo, mentre se i lavoratori sono vincolati, dovresti tenere traccia di un URL per ogni nuovo lavoratore, e dire al sink e/o vent del nuovo URL ogni volta che arriva un nuovo lavoratore.

* in realtà può essere importante in alcuni casi limite, ma non in generale.