Текущий архив: 2004.06.06;
Скачать: CL | DM;
Вниз
Сокеты, размер буфера Найти похожие ветки
← →
Zmey © (2004-04-10 19:44) [0]Народ, нужна маленькая помощь.
использую TIdTCPServer, в обработчике onExecute читаю буфер примерно так:
var buff: zasp_main;
begin
AThread.Connection.ReadBuffer(buff, sizeof(buff));
run_decode(buff, AThread.ThreadID);
end;
При некоторой итерации я так предпологаю скорее всего приходят данные "немножко" меньшего размера и он в процедуре ReadBuffer маленько подвисает, ..., т.е. насмерть.
Теперь вопрос, можно ли до чтения буфера узнать его размер?
За коментарии и советы буду признателен.
← →
Verg © (2004-04-10 20:47) [1]
> ReadBuffer маленько подвисает, ..., т.е. насмерть.
Судя по приведенному тобой коду это не должно тебя беспокоить.
Кодовоый поток, который обслуживает данного, конкретного клиента, только и делает, что считывает данные и их декодироует.
Connection.ReadBuffer так и устроен - он будет принимать данные, пока не примет их ровно в количестве второго параметра. А судя по процедуре run_decode, в которую явно не передается никак размер buff, то она может декодировать буфера строго определенного, заранее известного размера. Ни больше, ни меньше. Так на кой тебе знать "сколько", если все равно меньше тебе не надо?
← →
Zmey © (2004-04-10 21:22) [2]Ну например предположем такую ситуацию, что некий доброжелатель хочет подвесить сервер, подключится и пощлёт нестандартный пакет, ..., сервер подвиснет и будет ждать недостоющего размера, ..., а еслиб я знал размер пакета яб его мог прочитать с нужным размером и просто проигнорировать в случае неправильного размера.
Хотя она у меня и так виснет, ..., что мешает отладке :(. т.е. главный недоброжелатель это Я. вот...
← →
Verg © (2004-04-10 21:31) [3]Ну он "подвесит" не сервер, а только тот поток, который обрабатывает его соединение.
А что тебе даст информация о том, что в приемном буфере на некоторый момент времени нахродится меньше байт, чем тебе надо?
Или ты забыл, что TCP - поточный протокол и в общем случае порции, которыми пополняется входные буфера сокета на принимающей стороне не равны тем порциям, которыми ПО собеседника пополняет буфера передатчика своего сокета.
Тебе этот "неправильный", как ты считаешь, размер в какой-то момент времени может дать и совершенно легальный абонент.
← →
Polevi © (2004-04-10 21:44) [4]можешь предварять данные некой сигнатурой
← →
Zmey © (2004-04-16 05:40) [5]Тема такая. Всё из тойже песни.
делал раньше так (на стороне клиента):
repeat
if client.Connected then
begin
client.ReadBuffer(buff, sizeof(buff));
run_decode(buff);
end
else
sleep(1000);
until Terminated;
При этом создавал поток на onCreate программы, а убивал при её зовершении. В этом случае при реконекте (т.е. посылал Disconnect и соединялся как и до этого) перестовали поступать данные от сервере вплоть до подвисание сервера. Сервер на запросы от этого соеденения не реагировал. Что самое интересное Хендел потока при создании подключения на сервере остовался один и тот же, хотя после дисконекта поток пропадал.
В случае же когда я прересоздавал поток на стороне клиента при каждом реконекте работает нормально (вроде) и Хендл потока на сервере для этого подключения меняется... вот...
Есть у кого - нить какие нибудь идеи и предложения. Объясните дураку, в чём я не прав.
← →
Verg © (2004-04-16 09:35) [6]
> В этом случае при реконекте (т.е. посылал Disconnect и
> соединялся как и до этого) перестовали поступать данные
> от сервере вплоть до подвисание сервера. Сервер на запросы
> от этого соеденения не реагировал.
Кто, кому, что и как посылал?
Ничего непонятно....
Что значит "посылал disconnect"?
В приведенном коде есть только ReadBuffer. От кого перестали поступать данные? А они должны поступать? Если все только и делают, что ReadBuffer.......
Страницы: 1 вся ветка
Текущий архив: 2004.06.06;
Скачать: CL | DM;
Память: 0.46 MB
Время: 0.025 c