Есть сервер и клиенты, которые общаются по UDP в неизвестном формета. Мне нужно сделать UDP-прокси между сервером и клиентами (выдать себя за настоящий сервер). О формате общения я знаю только что оно происходит по принципу запрос-ответ. Т.к. ответы от реального сервера будут неотличимы с точки зрения того, для какого клиента они предназначены, я решил сделать так: клиенты приходят с запросом, я ставлю их в очередь, достаю по одному запросу, шлю реальному серверу, получаю ответ, и отдаю клиенту. Сначала я сделал так: Поток 1: request = recvfrom(client); // принимаем запрос от клиента request_queue.push(reqest); // ставлю его в очередь Поток 2: request = request_queue.pop(); sendto(server, request); recvfrom(server, response); sendto(client, response); Первая проблема заключалась в том, что ответ клиенту нужно отправлять по тому же сокету, с которого мы считали запрос. Теперь это мне кажется логично: если ответ отправить с другого сокета, то он придет с другого порта, а клиент может проверять, пришел ли ответ с того же порта, на который он отправлял. Тогда я решил что у меня должен быть один главный сокет, забайндиный на тот самый порт, и с которого я буду слать ответы. Но и это не удалось - после того как клиент закрывался, вызов recvfrom для этого сокета заканчивался ошибкой WSAECONNRESET 10054 An existing connection was forcibly closed by the remote host. Не понимаю, как такая ошибка может быть в UDP протоколе? Так как на один и тот же порт нельзя забайндить несколько сокетов, получается, что в UDP нельзя одновременно общаться с несколькими клиентами? Можно только последовательно отвечать на входящие запросы? Тогда непонятно, как быть, если между запросом и ответом проходит много времени, а клиенты ходят часто?
Я предпологаю,что в поле порта отправителя,запроса к серверу от твоего прокси нужно указать другой порт;забиндить еще один сокет на этот порт,чтобы слушать оба сокета. И RAW сокеты тебе в помощь.
like Я так и делаю! Один сокет - принимает запрос от клиента, и отправляет ему ответ. Второй сокет - отправляет запрос к настоящему серверу и читает с него ответ. Проблема в том, что первый сокет после получения запроса как бы прибивается к этому клиенту, и когда клиент уходит, умирает и сокет, что для UDP мне совершенно не ясно.
Очень странно.Листинг программы в студию,можно не целиком, только важные моменты (socket(),bind(),sendto(),recevfrom()).
Схематично: udp_accept_thread - принимает запрос и вставляет в очередь udp_interact_thread - обрабатывает очередь запросов За network::socket_ptr кроется винсокет, мемберфункции - одноименны Код (Text): udp_accept_thread() { udp_interface = network::socket_ptr(new network::socket(network::socket::udp)); // Этот же сокет используется в следующем потоке udp_interface->bind(udp); // Это IP+Port, на который принимаются пакеты от клиентов std::size_t const maxsize = 1024; while() { content.resize(maxsize); content.resize(sck->receivefrom(addr, &*content.begin(), content.size())); acquire_object(udp_queue); // Очередь запросов, RAII для захвата мутекса udp_queue.push_back(addr + content); } } udp_interact_thread() { network::socket_ptr sck(new network::socket(network::socket::udp)); // Это сокет для общения с настоящим сервером std::size_t const maxsize = 1024; while() { request_queue local_queue; { acquire_object(udp_queue); local_queue.swap(udp_queue); } if(local_queue.empty()) { sleep(1); } else while(!local_queue.empty()) { request const& req = local_queue.front(); sck->sendto(server, &*req.content.begin(), req.content.size()); response.content.resize(sck->receivefrom(response.addr, &*response.content.begin(), response.content.size())); udp_interface->sendto(req.source, &*response.content.begin(), response.content.size()); local_queue.pop_front(); } } }
Вот что сказано про ошибки recvfrom: WSAECONNRESET - The virtual circuit was reset by the remote side executing a hard or abortive close. The application should close the socket; it is no longer usable. On a UDP-datagram socket this error indicates a previous send operation resulted in an ICMP Port Unreachable message. Как это понимать? --- И еще: только что выяснилось, что существует событие, при котором взаимодействие происходит по принципу "запрос-запрос-ответ-ответ", что никак не вписывается в текущий алгоритм
Короче удалил все нафик, обдумал все еще раз, написал все с нуля и все заработало как часы. Плюс ко всему изначальная мысль о том, что будут проблемы с конкурирующим проксируемым трафиком оказалась фигней - клиенты работают параллельно через один прокси без проблем. Бывает...