Вы уже разобрались с одной проблемой в комментариях - connect()
является синхронным, и вы попытались использовать его асинхронно.
Я хотел бы предложить в node.js, что вы оба: bind()
и connect()
синхронно, вы получаете небольшую выгоду от запуска этого одноразового запуска асинхронно, и это просто делает код более четким, чтобы сделать это синхронно. Если вы наращиваете и разрываете сокеты в середине процесса, и у вас, честно говоря, есть все основания для этого, тогда вы можете игнорировать этот совет, но узел дает вам повод сделать это только один раз и использовать те же сокеты для жизни процесса.
касается того, как два разных сервера могут найти друг друга, ваш пример не получится:
// this tells the socket to listen to all incoming connections on post 5555
// but it does not create a connection to any other machine or process
requester.bindSync('tcp://*:5555');
... и на другой машине ...
// this tells the socket to connect to a bound socket on the same machine
// it will not find a socket on another machine
replier.connect('tcp://127.0.0.1:5555');
Таким образом, вы должны либо реверсе bind()
и connect()
, а затем изменить requester
, как в следующем примере:
// change 111.222.33.44 to the IP address or DNS name of your other machine
requester.connect('tcp://111.222.33.44:5555');
... и на другой машине ...
replier.bindSync('tcp://*:5555');
...или, измените свой вызов connect()
, чтобы указать IP-адрес первой машины, а не адрес обратной связи.
Ниже следует оценка того, с какой стороны вы должны connect()
или bind()
, поскольку я чувствую, что другой совет не является полным.
Это не имеет значения, с какой стороной вы bind()
или connect()
на, так долго, как вы bind()
на постоянной стороны (ваш «сервер») и connect()
на транзиторной стороны (ваш «клиент»). Если они одинаково устойчивы, то следующий способ выбрать: bind()
на стороне, которая «владеет» данными, как это делает сервер, и connect()
на стороне, которая «хочет» данные, как делает клиент.
Вот почему, традиционно, вы будете bind()
REP
гнездо и connect()
REQ
гнездо, как REQ
гнездо «хочет» данные, которые он запрашивает, и REP
гнездо «владеет» данные отправки обратно. Аналогично, вы будете bind()
a PUB
сокет, так как он «владеет» данными, которые он публикует, и вы будете connect()
a SUB
сокет, так как он «хочет» данные, на которые он подписан.
Это всего лишь правило, это вполне возможно для SUB
гнездо, чтобы быть более стойким, чем это компаньон PUB
гнездо, или для REQ
сокета «собственные» данные, которые он посылает в REP
гнездо. И во многих случаях вы можете выбрать любую сторону с нулевыми последствиями в любом случае, но это полезные правила, чтобы следовать, чтобы иметь определенную ясность в отношении того, что происходит.
Вы не смешиваете запросчика и не отвечаете? глядя на ваш код, запрашивающий прослушивает и ответ отвечает – dmaij