Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 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
1-1085576239
Kiloper
2004-05-26 16:57
2004.06.06
Как мне в TImage вывести gif рисунок


1-1085570198
BALU1111
2004-05-26 15:16
2004.06.06
2 вопроса


1-1085119168
IrBisoff
2004-05-21 09:59
2004.06.06
Правильная передача в Dll структуры данных.


3-1084562937
Ertong
2004-05-14 23:28
2004.06.06
select max from someDB


4-1083725758
Matveyev
2004-05-05 06:55
2004.06.06
Пункт меню с иконкой





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский