WSARecvFrom на неподключенном сокете UDP не возвращает

Question

Я пишу небольшую программу, которая тестирует сетевой сервис UDP.Реализация сервиса позволяет создать новый сокет для сеанса и оттуда ответить клиенту, после чего клиенту необходимо связаться с этим адресом (аналогично TFTP).

Минимальный клиентПроверка ошибок sans выглядит следующим образом:

int fd = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);

sockaddr_in destaddr = { ... };
MSGBUF msg[] = { ... };
DWORD sent;
WSASendTo(fd, msg, sizeof msg / sizeof *msg, &sent, 0, (sockaddr *)sa, sizeof sa, 0, 0);

char buffer[4096];
MSGBUF rcvmsg = { sizeof buffer, buffer };
DWORD received;
sockaddr_storage sa;
socklen_t sa_len = sizeof sa;
DWORD flags = 0;
WSARecvFrom(fd, &rcvmsg, 1, &received, &flags, (sockaddr *)&sa, &sa_len, 0, 0);

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

Явное связывание сокета с { AF_INET, INADDR_ANY, 0 } для принудительного назначения локального порта или вызов listen(fd, 5); не имеет значения, как и ожидалось.

Есть ли что-нибудь в WSASendToэто неявно соединяет сокет UDP, и если так, что я должен сделать, чтобы избежать этого?

Answer 1

У UDP нет соединений.Датаграммы отправляются в и из портов;это односторонняя связь.

Мне кажется, что ваш сервер разрешает себе назначить временный порт (т. е. передать 0 в качестве порта в sockaddr_in) вместо использования определенного порта.Это не сработает.

Поскольку UDP не имеет понятия соединения, каждый раз, когда вы отправляете данные, они могут отправляться с другого порта;первая отправка не резервирует порт, который был ей предоставлен, она просто отправляет с него дейтаграмму и затем отпускает ее.

Ваш сервер должен привязать себя к определенному порту.

Answer 2

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