Сервер ZeroMQ и клиент на одном ПК - PullRequest
Новая
       28

Сервер ZeroMQ и клиент на одном ПК

0 голосов
/ 12 мая 2018

Я использую этот шаблон для сервера на ZeroMQ: 

import time
import zmq

context = zmq.Context()
socket = context.socket(zmq.REP)
socket.bind("tcp://*:5555")

while True:
    message = socket.recv()
    print("Received request: %s" % message)
    time.sleep(1)
    socket.send(b"World")

и этот шаблон для клиента: 

import zmq

context = zmq.Context()
print("Connecting to hello world server…")
socket = context.socket(zmq.REQ)
socket.connect("tcp://localhost:5555")

#  Do 10 requests, waiting each time for a response
for request in range(10):
    print("Sending request %s …" % request)
    socket.send(b"Hello")

    #  Get the reply.
    message = socket.recv()
    print("Received reply %s [ %s ]" % (request, message))

Как использовать связь сервер-клиент и клиент-сервер одновременно на одном ПК?

Нужно ли создавать нити для достижения этой цели?

Необходимо, чтобы компьютер мог отправлять данные и одновременно получать и обрабатывать их с других компьютеров.

P.S .: может это решить мою проблему?

Ответы [ 2 ]

0 голосов
/ 17 сентября 2018

Вы можете публиковать и подписываться на другой сервер одновременно, используя тот же код, согласно этому примеру из ZMQ 

import zmq
import time
context = zmq.Context()

subscriber = context.socket (zmq.SUB)
subscriber.connect ("tcp://192.168.55.112:5556")
subscriber.connect ("tcp://192.168.55.201:7721")
subscriber.setsockopt (zmq.SUBSCRIBE, "NASDAQ")

publisher = context.socket (zmq.PUB)
publisher.bind ("ipc://nasdaq-feed")

while True:
    message = subscriber.recv()
    publisher.send (message)

Итак, вы являетесь подписчиком, подключенным к этим двум серверам 

 subscriber.connect ("tcp://192.168.55.112:5556")
 subscriber.connect ("tcp://192.168.55.201:7721")

в то же время вы вещаете как издатель publisher.send (сообщение)

Так вы бы построили одноранговую распределенную систему, каждый сервер подписчик и издатель

0 голосов
/ 12 мая 2018

может запускать этот клиент много раз параллельно

Ну, на самом деле не может .
Хотя это утверждение, как полагают, было представлено в доброй воле, чтобы что-то объяснить, оно может и на самом деле сильно подрывает общую точку зрения информатики о том, как все работает, поскольку оно ужасно вводит в заблуждение.

Оператор локального хоста может запускать клиентский код на основе ZeroMQ много раз одновременно [True]
может выполнять клиентский код на основе ZeroMQ много раз одновременно [True]
[любая экосистема] может выполнять клиентский код на основе ZeroMQ много раз параллельно [False]

Никто не может и никогда не будет. Ни один превосходный язык параллельной обработки Cray не может этого добиться, поскольку ZeroMQ - это, в основном, асинхронная, "просто" - [CONCURRENT] экосистема планирования процессов, где каждый основной механизм, работает внутри каждого из Context() -экземпляров, работает внутренний пул из 1+ потоков ввода-вывода (ну, фактически, 0+, если пуристы требуют особого случая: o)), как известно, является асинхронным по своей сути и не зависит от потока внешних событий, так что действительно никогда не может быть истинным - [PARALLEL] планирование процесса может появиться здесь.

Вначале можно прочесть краткий обзор вводного представления об основных концептуальных элементах, кратко изложенный в разделе [ Иерархия ZeroMQ менее чем за пять секунд ], так как Помогите нам говорить на одном языке, чтобы глубже взглянуть на возможности домена на базе ZeroMQ.

Как использовать связь сервер-клиент и клиент-сервер одновременно на одном ПК?

Легко:
Один компьютер может сначала запустить интерпретатор Python, выполняющий код server.py. Затем можно запустить второй интерпретатор Python (будь то в другом терминале Linux, или в окне Windows или cmd -shell) и запустить код client.py. Это будет работать как шарм.

Если вас интересуют подробности, имейте в виду, что REQ/REP Масштабируемый формальный образец археологического обмена принципиально опасен для любого профессионального кода профессионального уровня, поскольку он может (и будет) легко превращаться в принципиально невозможную, не подлежащую спасению взаимную взаимную блокировку (просто распределенная пара FSA: FSA может перейти в состояние мертвой блокировки, из которой ни одна из сторон не может спасти и продолжить поток взаимного сотрудничества)

Нужно ли создавать нити для достижения этой цели?

Ну, на самом деле, многие потоки уже работают "изнутри", если нет других, есть несколько потоков уже внутри каждого python + ZeroMQ Context() композиция.

Если вы намеревались указать коду Python, чтобы он начал использовать большее количество потоков, о таких намерениях должно быть больше подробностей, прежде чем можно будет помочь в решении этой дилеммы. Есть также главный недостаток использования потоков - известная Python GIL-блокировка фактически делает любую такую ​​попытку в чисто-1079 *[SERIAL], да, пошаговое последовательно упорядоченное выполнение кода (как это помогает сохранить влияние GIL-протектора на монопольный доступ к данным (выполнение кода [SERIAL] никогда не приводит к коллизионному случаю неатомарной записи (записей), тем меньше условие гонки, поскольку GIL-степпинг фактически делает каждая операция - атомарный шаг - конечно, ценой прерывания, [SERIAL] GIL-пошаговое выполнение всех графов выполнения кода пула потоков. Безопасно? Хорошо, да, но медленнее, чем необходимо).

Лучший следующий шаг?

Если действительно серьезно и стремиться погрузиться в проект [распределенной системы], лучшим следующим шагом будет чтение невероятной книги Питера ХИНТЖЕНСА [ Code Connected, Volume 1 ] (pdf онлайн), где все время и усилия хорошо вознаграждаются благодаря получению тщательно продуманных практических взглядов и большого количества опыта, так что необходимо выжать из ZeroMQ как можно больше, и это доставит дальнейшие умные разработки.

Оставайтесь с нами, это шаг в правильном направлении.

...