Как избежать ограничений на передачу через сокет UDP? - PullRequest
Новая
       30

Как избежать ограничений на передачу через сокет UDP?

0 голосов
/ 26 сентября 2010

Я пишу небольшую программу, которая отправляет файл от клиента к серверу через соединение через сокет udp .. Программа работает правильно, но если размер передаваемого файла превышает 8192 КБ, поток останавливается, а полученный файл поврежден .. Как я могу избежать этого ограничения?

server.py 

host = ...
port = ...
filename = ...

buf = 2048
addr = (host, port)

UDPSock = socket(AF_INET, SOCK_DGRAM)
UDPSock.bind(addr)

f = open(filename, 'wb')

block,addr = UDPSock.recvfrom(buf)
while block:
    if(block == "!END"): # I put "!END" to interrupt the listener
        break
    f.write(block)
    block,addr = UDPSock.recvfrom(buf)

f.close()
UDPSock.close()

client.py 

host = ...
port = ...
filename = ...

buf = 2048
addr = (host, port)

UDPSock = socket(AF_INET, SOCK_DGRAM)

f = open(filename, 'rb')

block = f.read(buf)
while block:
        UDPSock.sendto(block, addr)
        block = f.read(buf)

UDPSock.sendto("!END", addr)
f.close()
UDPSock.close()

Ответы [ 6 ]

2 голосов
/ 26 сентября 2010

Вы должны разбить файл на более мелкие куски перед отправкой t. 8192 довольно большой, и я думаю, что вы можете столкнуться с проблемами при отправке этого через Интернет, вместо этого я бы использовал 512 байт. Также помните, что UDP не является надежным протоколом, то есть некоторые из ваших пакетов могут вообще не приходить. Я предлагаю использовать TCP для передачи файлов, это решает все проблемы, которые вам придется решать самостоятельно при использовании UDP.

1 голос
/ 27 сентября 2010

Если вам нужно использовать UDP, посмотрите на http://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol

Это определяет надежный протокол. Если ваш контекст позволяет TCP, вы должны использовать это.

1 голос
/ 27 сентября 2010

Вы все еще не объяснили, почему вы должны использовать UDP - он просто не предназначен для передачи больших объемов данных, поскольку не имеет (простого) управления перегрузкой.

Если вы отправляете VoIPзатем, когда не просто передать в режиме реального времени, а не «как можно быстрее»?

FWIW, типичные системы VoIP пакетируют данные в 20-миллисекундные порции или около того.Следовательно, если вы используете голосовой кодек, такой как GSM, который требует 13 кбит / с, вам нужно всего лишь разбить на 260 бит (~ 32 байта) на пакет и отправлять их каждые 0,02 секунды.

1 голос
/ 27 сентября 2010

Все, что вы делаете, - это очень плохое повторное внедрение TCP, единственной причиной для использования UDP должна быть передача 1-ко-многим или постоянно работающее промежуточное ПО служебной шины предприятия.

Использование UDP в качестве ненадежного однонаправленного транспорта следует рассматривать как очень маленькое нишевое решение после исчерпания существующих четко определенных транспортных средств.

Примечание: для больших объемов данных, передаваемых через Интернет, строчные буквы "I" по-прежнему надежны, и вы обычно должны добавлять кадрирование приложений и проверку полезной нагрузки.

Я бы рекомендовал изучить существующие технологии передачи файлов, такие как FSP (UDP), HTTP (TCP), SPDY (оптимизированный HTTP) или для интеграции с другими коммуникациями, выходящими за пределы существующей системы промежуточного программного обеспечения, например JBoss или 0MQ .

1 голос
/ 26 сентября 2010

Предел 8192, который вы установили, соответствует размеру буферов отправки и получения сокетов в Windows.Я удивлен, что это работает вообще для файлов больше 1460 байт, так как пакеты были бы обрезаны до этого или меньше, прежде чем они были бы помещены в провод.Проводили ли вы тестирование на одном и том же хосте?

Когда вы это выяснили, вам придется иметь дело с пакетами, поступающими не по порядку, более одного раза или вообще нет.Вы уверены, что должны использовать UDP?Это не для непосвященных.

1 голос
/ 26 сентября 2010

было бы неплохо использовать tcp для передачи больших файлов.

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

С tcp вы не делаете.

...