1

Я пытаюсь отправить файл через беспроводную сеть с использованием ZeroMQ и протокола NORM. Насколько я понимаю, в настоящее время я использую шаблон PUB/SUB, поскольку это единственный шаблон, поддерживаемый NORM с ZeroMQ.Использование ZEROMQ и NORM для многоадресных пакетов для большого количества устройств WiFI

У меня он настроен так, что небольшие сообщения передаются просто отлично, но иногда приемник обычно не получает сообщение. С этого момента сообщения просто отбрасываются. Иногда это может быть исправлено путем перезапуска издателя или подписчика, но не каждый раз. Я попытался настроить бит отправленных бит и время между каждым вызовом для отправки безрезультатно. Похоже, я могу получать около 20-60 сообщений многоадресной рассылки до того, как соединение станет неустойчивым. Если я использую тот же код, но настрою его с помощью TCP, соединение намного надежнее, порядка тысяч сообщений до возникновения ошибки.

Я попытался реализовать класс-оболочку, чтобы перезапустить подписчиков после определенного периода бездействия - это не сработало. Также не устанавливает параметр socket.recv (zmq.NOBLOCK) внутри цикла while.

Я знаю о Pub-Sub шаблон синхронизации, как описано здесь, http://zguide.zeromq.org/page:all#Node-Coordination, но NORM, как это реализовано в norm_engine.cpp в ZeroMQ в (https://github.com/zeromq/libzmq/blob/master/src/norm_engine.cpp) не выглядит, как он настроен, чтобы этот шаблон.

Есть ли способ повторно отправить потерянные пакеты или обеспечить здоровое многоадресное соединение?

Код - Python.

Издательство:

import zmq 
import time 
import os 
context = zmq.Context() 
socket = context.socket(zmq.PUB) 
socket.connect("norm://224.0.0.1:3000") 
i = 1 

imgfile_path = "/home/adam/programs/zmq/tux.svg.png" 
imgsize = os.stat(imgfile_path).st_size 
print "attempting to send", imgsize, "bytes" 

sleep_time = 1 
topic = "" 
packet_size = 500 
left = packet_size 
f = open(imgfile_path, 'rb') 
fi = f.read(packet_size) 
while (imgsize - left) > packet_size: 
    print "sent packet number:", i 
    print "size: ", len(topic + str(i)[-1] + fi) 
    i += 1 
    socket.send(topic + str(i)[-1] + fi) 

    fi = f.read(packet_size) 
    left += packet_size 
    time.sleep(sleep_time) 
print imgsize, left 
time.sleep(sleep_time) 
fi = f.read(imgsize - left) 
print fi 
socket.send(topic + " " + fi) 
f.close() 

Subscriber:

import zmq 
context = zmq.Context() 
socket = context.socket(zmq.SUB) 
socket.bind("norm://224.0.0.2:3000") 
socket.setsockopt(zmq.SUBSCRIBE, "") 

imgdir = "/home/adam/programs/zmq/img/" 
filename = "tux.svg.png" 
destfile = imgdir + filename 
packet_size = 501 
print "attempting to receive" 
f = open(destfile, 'wb') 
while True: 
    msg = None 
    while msg is None: 
     try: 
      msg = socket.recv(zmq.NOBLOCK) 
     except: 
      pass 
    if msg: 
     print "msg = ", msg[0] 
     print "we got something", len(msg) 
     f.write(msg[1:]) 
     if len(msg) < packet_size: 
      break 
f.close() 
print "exiting..." 

Кроме того, когда я могу гарантировать, что я могу отправить файл, я хотел бы, чтобы настроить прямое исправление ошибок и NACK скорость, которая почему NORM так полезен для меня. Есть ли способ сделать это, не переписывая norm_engine.cpp?

Спасибо!

ответ

1

Некоторые из вещей, которые вы предполагаете, подтверждаются на странице документа here. А именно, что на данный момент это только PUB/SUB, хотя у вас есть возможность выполнить синхронизацию, связанную с использованием NORM для PUB/SUB и TCP для REQ/REP.

В противном случае, я считаю, вы страдаете от этого еще довольно рано на этапе реализации NORM, так как (также из моей ссылки) он говорит обо всех вещах, которые еще не сделаны. Это было год назад, но я не вижу много там разговоров об этом с тех пор.

В зависимости от особенностей вашей инфраструктуры многоадресная рассылка может быть даже не лучшим выбором, как обсуждалось here, ни один из протоколов многоадресной рассылки не предназначен для современных высокопроизводительных сетевых скоростей. Может быть, ваша реализация становится жертвой плохого восстановления от проблем, которые возникают как естественное следствие этих транспортных протоколов.

EDIT:

За ссылку GitHub в вашем посте, код не был обновлен с 3/19/14, в тот же день на странице я связан выше была опубликована, так что все, что он говорит о NORM транспорт в ZMQ должен быть полностью обновлен.

В нижней части страницы, в точках о том, что реализация NORM ZMQ может и не может сделать:

  1. Ток «norm_engine» предполагает довольно специфическую форму вариантов NORM транспорта. Может оказаться желательным выявить дополнительные функции NORM и методы транспорта через ZeroMQ API. Некоторые примеры включают в себя:
    • Способность NORM альтернативно предоставлять UDP-подобные «наилучшие усилия» и «лучше, чем лучшее усилие» (с использованием кодирования стирания пакетов) для приложений. Это будет включать в себя контроль параметров кодирования NORM FEC.

Таким образом, похоже, что он не делает (в его текущем состоянии) дает вам никакого контроля над прямым исправлением ошибок, просто использовать его в реактивном (высокой производительности) состояние по умолчанию. Этот должен обеспечить надежность вашего соединения по умолчанию, но если реализация ZMQs не была тщательно проделана через его шаги, она может быть более хрупкой, чем вам хотелось бы. Из-за отсутствия контента и патчей на нем я бы предположил, что он еще не готов для вас.

+0

Спасибо. Я пытаюсь вытолкнуть границы многоадресной рассылки и подумал, что можно передавать данные таким образом. Надеемся использовать прямую коррекцию ошибок NORM для снижения скорости. Вы слышали об этом? – scordata

+0

Обновлен мой ответ с более подробной информацией о FEC – Jason

Смежные вопросы