Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2005.12.11;
Скачать: CL | DM;

Вниз

Проблема с Socket.ReceiveBuf   Найти похожие ветки 

 
Gektor   (2005-09-01 11:31) [0]

В событии OnRead пишу:

var i : Integer;
   Len : Integer;
   pbuf : PMyArray;

begin
{Принимаем данные и ложим сразу в конец IncomingBuff}
while (Socket.ReceiveLength > 0) do
begin
Len := Socket.ReceiveLength;
i := 0;
try
pbuf := Pointer(fIncomingBuf^[fIncomingBufLen]);
i := Socket.ReceiveBuf(pbuf,Len);
except
AddToDebugLog("Error with receiving Some Data");
end;

и тд...

в Отладчике в первый же раз, при выполнении строки i := Socket.ReceiveBuf(pbuf,Len); выдает окошко CPU и вылетает с ошибками.

Буферы точно созданны.
fIncomingBufLen = 0.
В Len не нулевое значение.
PMyArray Указатель на array[0 .. 7999]

В чем можеть быть проблема?


 
Digitman ©   (2005-09-01 11:53) [1]

Паскаль нужно знать как "Отче наш" !

i := Socket.ReceiveBuf(pbuf^,Len);

к тому же еще и логика неверна ..
зачем тут цикл понадобился, спрашивается ?


 
Gektor   (2005-09-01 12:13) [2]


> Digitman ©

i := Socket.ReceiveBuf(pbuf^,Len); и сразу отрабатывает OnError


 
ALI_YES   (2005-09-01 12:23) [3]

Действительно Паскаль надо знать.
Но если тебе надо передавать большие объемы данных, то тебе лучше испльзовать класс TWinSocketStream.


 
Digitman ©   (2005-09-01 12:44) [4]


> сразу отрабатывает OnError


это уже из другой оперы.

к тому же никаких "сразу" быть не может.

ReceiveBuf  - синхронный блокирующий метод, он либо отрабатывает успешно (т.е. после выполнения возвращает управление на следующий за вызовом ReceiveBuf оператор ) либо возбуждает исключение.

Учимся пользоваться встроенным в Делфи-среду отладчиком !


 
Digitman ©   (2005-09-01 12:47) [5]


> ALI_YES   (01.09.05 12:23) [3]
> если .. надо передавать большие объемы данных, то ..
> лучше испльзовать класс TWinSocketStream.


глупости.

возможность и/или необходимость использования класса TWinSocketStream никак не зависит от объемов транспортируемых данных

возможность зависит от Client/ServerType

необходимость зависит от реально имеющейся возможности + фантазии


 
ALI_YES   (2005-09-01 12:52) [6]


> Digitman ©   (01.09.05 12:47) [5]

Я знаю, просто кому-нибудь это показалось бы удобней


 
Digitman ©   (2005-09-01 13:25) [7]


> ALI_YES   (01.09.05 12:52) [6]


судя по OnRead ни о каких TWinSocketStream не может идти и речи.
автор выбрал асинхронный неблокирующий режим.


 
ALI_YES   (2005-09-01 14:30) [8]


> Digitman ©   (01.09.05 13:25) [7]

Хорошо, пусть он выбрал.
Но, ты считаешь, что

> асинхронный неблокирующий режим.
более удобен?


 
Digitman ©   (2005-09-01 14:37) [9]


> ALI_YES   (01.09.05 14:30) [8]


я считаю, что прежде чем давать советы в [3] нужно внимательно изучить сабж.

сабж же говорит об выборе (осознанном или неосознанном - неважно) автором режима ctNonBlocking, для которого TWinSocketStream неприменим в принципе.


> более удобен?


причем здесь "удобство" ?



Страницы: 1 вся ветка

Текущий архив: 2005.12.11;
Скачать: CL | DM;

Наверх




Память: 0.49 MB
Время: 0.06 c
3-1130481790
surkis
2005-10-28 10:43
2005.12.11
имя SQL Servera


2-1132577865
Igor_thief
2005-11-21 15:57
2005.12.11
Active Desktop


3-1130324285
Карелин Артем
2005-10-26 14:58
2005.12.11
Использование нескольких наборов записей из одного запроса.


6-1125535648
DeathLess
2005-09-01 04:47
2005.12.11
Скачать файл с докачкой


6-1125262668
Временный Гость
2005-08-29 00:57
2005.12.11
Отправка email письма с помощью компонента idSMTP