Python ICMP ping реализация при пинге нескольких ips из потоков?

Question

Я использовал jedie's python ping implementation на Windows. Я мог ошибаться, но когда пинг двух компьютеров (A и B) из отдельных потоков, ping вернет первый пинг, который он получает, независимо от источника.

Поскольку это может быть проблема с вилкой джедая, я reverted to the previous version. (Это версия, которую я собираюсь исследовать ниже)

Я добавил в строке кода в receive_one_ping: (строка 134 или аналогичный)

recPacket, addr = my_socket.recvfrom(1024) # Existing line 
print "dest: {}, recv addr: {}.".format(dest_addr, addr) # New line 

Это позволяет увидеть адрес пинг мы получаем. (Должен быть такой же, как назначения IP, не так ли?)

Тестирование:

ping1() пингует известный автономный IP (1.2.3.4),
ping2() пингует известный онлайн-IP (192,168 .1.1 - маршрутизатор)

>>> from ping import do_one 

>>> def ping1(): 
    print "Offline:", do_one("1.2.3.4",1) 

>>> ping1() 
Offline: None 

>>> def ping2(): 
    print "Online:", do_one("192.168.1.1",1) 

>>> ping2() 
Online: dest: 192.168.1.1, recv addr: ('192.168.1.1', 0). 
0.000403682590942 

Теперь, если мы делаем их вместе: (Использование таймера для простоты)

>>> from threading import Timer 
>>> t1 = Timer(1, ping1) 
>>> t2 = Timer(1, ping2) 
>>> t1.start(); t2.start() 
>>> Offline:Online: dest: 192.168.1.1, recv addr: ('192.168.1.1', 0).dest: 1.2.3.4, recv addr: ('192.168.1.1', 0). 

0.0004508952953870.000423517514093 

Это немного искажаются (за счет печати не работает хорошо с резьбой), поэтому здесь немного яснее:

>>> Online: dest: 192.168.1.1, recv addr: ('192.168.1.1', 0). 
Offline:dest: 1.2.3.4, recv addr: ('192.168.1.1', 0). # this is the issue - I assume dest should be the same as recv address? 

0.000450895295387 
0.000423517514093 

Мои вопросы:

1. Можно ли воссоздать это?

2. Должен ли пинг вести себя следующим образом? Я предполагаю, что нет.

3. Есть ли существующий ICMP-пинг для python, который не будет иметь такое поведение?
   В качестве альтернативы, можете ли вы придумать легкое исправление - то есть опрос receive_one_ping, пока наш пункт назначения не соответствует нашему получателю?

Edit: Я создал вопрос на python-ping github page

Answer 1

Это происходит из-за природы протокола ICMP. ICMP не имеет понятия портов, поэтому все ICMP-сообщения принимаются все прослушиватели.

Обычный способ устранения неоднозначности - установить уникальный идентификатор в полезной нагрузке ICMP ECHO REQUEST и найти его в ответе. Этот код выглядит так, но он использует текущий идентификатор процесса для создания идентификатора. Поскольку это многопоточный код, они будут совместно использовать идентификатор процесса, и все слушатели в текущем процессе будут думать, что все ECHO REPLY - это те, которые они сами отправили!

Вам необходимо изменить переменную ID в do_one(), чтобы она была уникальной для каждой нити.Вам нужно будет изменить эту строку в do_one():

my_ID = os.getpid() & 0xFFFF 

Возможно это будет работать в качестве альтернативы, но в идеале вы должны использовать реальный 16-битный хэш-функции:

# add to module header 
try: 
    from thread import get_ident 
except ImportError: 
    try: 
     from _thread import get_ident 
    except ImportError: 
     def get_ident(): 
      return 0 

# now in do_one() body: 
my_ID = (get_ident()^os.getpid()) & 0xFFFF 

Я DON» t знать, есть ли в этом модуле какие-либо другие проблемы с потоком, но кажется, чтобы быть в порядке от беглого экзамена.

Используя реализацию джедая, вы сделаете аналогичное изменение для аргумента конструктора Ping()own_id. Вы можете либо передать в ид вы знаете, чтобы быть уникальным (как выше) и управлять Ping() объектов самостоятельно, или вы можете изменить эту линию (110) в конструкторе:

self.own_id = os.getpid() & 0xFFFF 

Также см this question and answer and answer comment thread для получения дополнительной информации.