Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Сети > sockets: в чём я ошибаюсь?

Автор: Apel 31.8.2006, 01:24

Основной код: Код #define RSP_RCON_NUM     "яяяяchallenge rcon" #define RSP_SRV_DETAILS  "яяяяdetails" Код int CHLDSManager::Query(char *Address, u_short Port, char *QueryString) {   WSADATA WSAData;   if (!WSAStartup(WINSOCK_VERSION, &WSAData))   {     SOCKET Socket;      if ((Socket = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) != INVALID_SOCKET)     {       sockaddr_in to;       to.sin_family = AF_INET;       to.sin_port = htons(Port);       to.sin_addr.S_un.S_addr = inet_addr(Address);       int sended;       if ((sended = sendto(Socket, QueryString, (int)strlen(QueryString), 0, (sockaddr *)&to, sizeof(to))) != SOCKET_ERROR)       {     sockaddr from;     int recved, from_size = sizeof(from);     if ((recved = recvfrom(Socket, Buffer, sizeof(Buffer), 0,(sockaddr *) &from, &from_size)) != SOCKET_ERROR)     {       WSACleanup();       return recved;     }       }     }   }   WSACleanup();   return -1; } Код void CHLDSManager::Refresh(void) { //int Query(char *Address, u_short Port, char *QueryString);   if(CHLDSManager::Query("85.196.218.188", 27017, <qstr> ) > 0)   {     MessageBoxA(0, Buffer, "Buffer Content", 0);   } } Когда третий параметр функции Query равен RSP_RCON_NUM, всё в порядке, функция получает ответ сервера (соответствующий запросу). Когда же третий параметр равен RSP_SRV_DETAILS, функция recvfrom "зависает". Буфер для получаемых данных заведомо большего размера. Предпологаю, что она ждёт, пока сервер ответит? Известно точно, что сервер всегда отвечает на правильные запросы. Пробовал менять серверы, результат один. И, самое интересное, этот код совсем недавно прекрасно работал. Не пойму, что я мог такого изменить, что вдруг перестало работать. Помогите разобраться.

Автор: Apel 31.8.2006, 05:15

Написал весь код заново. работает на одном сервере. На остальных не хочет, опять проблемы с получением данных. Может, надо как-то по-особому данные получать? Возможно такое, что, раз протокол UDP, то данные 100% теряются? Хотя, другие программы получают эти же данные без проблем.

Автор: ptr 31.8.2006, 06:47

Apel, что за сервера то? Цитата(Apel @  31.8.2006,  09:15 ) Возможно такое, что, раз протокол UDP, то данные 100% теряются? Возможно.

Автор: Apel 31.8.2006, 07:43

Но ведь другие клиенты для данного сервера, по такому же протоколу получают данные, и для одного-единственного сервера данные получаю в полном объёме. А для других серверов не приходят данные большого объёма. Может, они застрявают в каком-нибудь буфере?

Автор: ptr 31.8.2006, 08:08

Apel, давай по порядку. 1. Что за сервера? 2. Ты переписал программу, так новый давай код. Цитата(Apel @  31.8.2006,  11:43 ) Но ведь другие клиенты для данного сервера, по такому же протоколу получают данные, и для одного-единственного сервера данные получаю в полном объёме. UDP не даёт никаких гарантий.

Автор: Apel 31.8.2006, 12:18

Код int CHLDSManager::Query(char *Address, u_short Port, char *QueryString) {   WSADATA WSAData;   int recved;   if (!WSAStartup(WINSOCK_VERSION, &WSAData))   {     SOCKET Socket;      if ((Socket = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) != INVALID_SOCKET)     {       sockaddr_in to;       to.sin_family = AF_INET;       to.sin_port = htons(Port);       to.sin_addr.S_un.S_addr = inet_addr(Address);       int sended;       if ((sended = sendto(Socket, QueryString, (int)strlen(QueryString), 0, (sockaddr *)&to, sizeof(to))) != SOCKET_ERROR)       {     sockaddr from;     int from_size = sizeof(from);     if ((recved = recvfrom(Socket, Buffer, sizeof(Buffer), 0,(sockaddr *) &from, &from_size)) != SOCKET_ERROR)     {         if(closesocket(Socket) != SOCKET_ERROR)       {         if(WSACleanup())return RET_FAIL;       }       }           }     }   }   return recved; } вот "новый" код. Он работает. Но почему-то функция recvfrom при получении большого ответа на запрос (большого, относительно других, на которые ответы приходят правильно и сразу) не завершается. Относительно серверов - это игровые серверы Counter-Strike, данная функция предназначена для получения разной информации о сервере в соответствии с протоколом. На одном сервере этот код замечательно работает. И на разных тоже работал, но вдруг перестал. Даже на локальном сервере не приходят некоторые ответы. То, что протокол UDP не гарантирует доставку пакетов я знаю, но ничего не поделать, если сервер желает общаться только по UDP, и то не всегда

Автор: sOckets 31.8.2006, 16:59

Почему бы не отметить что вопрос решён ? =\ что так трудно это сделать ?

Автор: Apel 31.8.2006, 17:58

Цитата(ilovewinsocks @ 31.8.2006,  16:59) Почему бы не отметить что вопрос решён ? =\ что так трудно это сделать ? Если бы Вы внимательно читали, то поняли бы, что вопрос не решён. Код переписан заново, но не отличается практически от предыдущего, а в плане получения данных от сервера идентичен. Вопрос заключается в том, что этот код то работает, то нет. Функция recvfrom отказывается получать данные по правильному запросу от всех серверов, кроме одного выдающегося неизвестно чем. До создания класса я проводил эксперимент с простой функцией, на разных серверах, по всем запросам приходили правильные ответы. Вопрос остаётся открыт: что может мешать функции recvfrom получить данные размером менее 200 байт?

Автор: sOckets 1.9.2006, 18:16

До этого он был решён по вашим словам. Затем появилась другая проблема.Вы же сами это видите так как это ваша тема, так зачем же просто так обижать участника форума заявив что он не внимательно читает Темы. ?

Автор: ptr 2.9.2006, 05:11

Apel, а ты уверен в том, что серверы действительно посылают ответ?

Автор: Apel 2.9.2006, 07:41

2 ilovewinsocks: Прошу прощения, если мои слова показались Вам обидными, я не хотел никого обижать. Пояснение: если я сказал, что код работает, это значит, в нём нет логических или синтаксических ошибок, но не то, что результат его работы верный. 2 ptr: Интересный вопрос. Я знаю точно, что этот протокол открытый и серверы должны отвечать на запросы. У сервера нет возможности отключать обработку как определённых запросов, так и обработку всех подобных запросов в принципе - это не настраивается. Формат запроса тоже не мог поменяться, или, по крайней мере, существует обратная совместимость запросов. При тестировании на локальном сервере тоже не удаётся получить ответ на некоторые запросы, но раньше я получал от него ответы на все запросы, а в сервере ничего не менял. Я склоняюсь к тому, что сервер всё-таки отправляет ответ, ведь тестировал не на одном сервере. Может ли быть где-то промежуточный буфер, который меньшего размера, чем получаемые данные? Если может быть, то как в него залезть?

Автор: sOckets 2.9.2006, 09:11

Ничего страшного , просто мне показалось что вам помогли , вопрос решён, а в опциях вы не отметили.Прости меня за наглость

Автор: ptr 2.9.2006, 14:17

Apel, ну ты посмотри приходят ли данные (например с помощью Ethereal).

Автор: Apel 4.9.2006, 15:31

так-с! Скачал программу. Установил, сделал фильтр по UDP, включил монитор и отправил запрос. Далее я не пойму: либо данные отправляются не те, что я отправляю, либо серверы не отвечают. Там, где в пакете данные вместо конца, например,  Код FF FF FF FF 64 65 74 61 69 6C 73 // ASCII яяяяdetails [/co=nocolor] de] Такое: Код FF FF FF FF 64 00 00 00 00 00 00 // ASCII яяяяd...... Если данные уходят неправильные, неудивительно, что нет ответа. Но более длинные запросы выполняются правильно. Мистика какая-то.

Автор: dumb 4.9.2006, 15:49

в sendto строка отдается правильная?

Автор: ptr 4.9.2006, 16:15

Apel, давай всю программу.

Автор: Apel 9.9.2006, 03:43

Цитата(dumb @ 4.9.2006,  15:49) в sendto строка отдается правильная? Правильная. Я задавал её вручную и с помощью #define, не вижу разницы в конечном исходе дела. Добавлено @ 03:46  Цитата(ptr @ 4.9.2006,  16:15) Apel, давай всю программу. Да, собственно, я всё и выложил. Там больше ничего не делается, так как на данном этапе происходит нечто. То, что я выложил вполне рабочий код был, и с сетью больше никакая функция не работает.

Автор: Apel 25.9.2006, 05:48

Тему закрываю. Они, кажется, поменяли протокол, но по-русски об этом не написано.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)