Запись буфера помогите?

← →
r.o.o.t © (2007-07-30 17:30) [40]

лан все фигня вот следующий вопрос

GetMem(bufA,LengthA);
Socket.ReceiveBuf(bufA^, LengthA);
Reply:=StrPas(bufA)
SockHWND:= StrToInt(ClientID.Strings[i]);
for j := 0 to ServerSocket1.Socket.ActiveConnections - 1 do
if ServerSocket1.Socket.Connections[j].SocketHandle=SockHWND then
begin
ServerSocket1.Socket.Connections[j].SendBuf(bufA^,Length(bufa));
end;

FreeMem(BufA);

Почему происходит утечка памяти???
т.е. размер приложения в памяти растет на велечину LengthA+30
как это возможно ? неправельно освобождается bufA??

← →
DVM © (2007-07-30 17:34) [41]

> Почему происходит утечка памяти???
> т.е. размер приложения в памяти растет на велечину LengthA+30
>

Это ты как выяснил? В Диспетчер задач не гляди - там цифры странные несколько. Проверь c пом. FastMM4 или MemProof

← →
r.o.o.t © (2007-07-30 17:42) [42]

а поподробнее..... код встудиюю

ну я на цифры посматрел сервак обслуживает условно 20 клиентов был в памяти 14203 стал 18203 и потихонечку растеть т.е. помере передачи информации.............

← →
Evgeny V © (2007-07-31 08:13) [43]

> Сергей М.

Ваша лексика не вызвает к вам ни уважения, ни доверия к вашим знаниям. Кстати пройтись по постам я вам предложил, что бы вы посмотрели на свои слова, как вы общаетесь с людьми. Это не только в этой ветке, но и в других. Аргументов у вас ноль. И видно что вы не глупый, но придуриваетесь явно, или как говорят шлея под хвост - как с тем тестом что я вам дал. Сама не сделали, ни исправили, если уж вам так приспичило на олиночной посылке проверить SendBuf, ни предложили своего варианта. Аргументов у вас почти ноль. Есть верные мысли -о проверки возврата методов, о том, что вряд ли найдется необходимость получать количество данных при использовании сокетов (по крайней мере блокирующих), но тем не менее такой подход есть, в том числе и у MS. И создается впечатление, что вы усвоили штампы, верные штампы. Но знаний по теме у вас практически нет. Возможно я ошибаюсь, но обратных аргументов этому вы привести не смогли. Код борланда, который вы привели ничего не доказывает. Скажите мне причину, при которой будет считано меньше байт из буфера, чем заказано и эти байты там есть и доcтупны? Причина - ошибка операции чтения. Об этом говорилось. Спорить вы не умеете, объяснять вам что-то не охото, как и слушать ваши виляния -" то так то этак, а может так " А засим разрешите откланяться, хамовитый вы наш. Думаю вас это все равно не проймет, ибо хамство судя по всему у вас стиль жизни.

← →
Сергей М. © (2007-07-31 08:47) [44]

> r.o.o.t © (30.07.07 17:25) [39]

> думаю всегда будет i=j

Еще раз вникни в [6].

> при ReceiveText невсегда реч шла о методе ..Receivebuf

см. [34]

ReceiveText сводится к вызову ReceiveBuf.

При этом длина результ.строки сначала устанавливается равной amount of data (ReceiveLength тоже сводится к вызову ioctlsocket(FIONREAD)), а затем эта длина может быть уменьшена до фактического (положительного) размера, возвращенного вызовом ReceiveBuf.

← →
Сергей М. © (2007-07-31 08:51) [45]

> r.o.o.t © (30.07.07 17:30) [40]

Тоже самое касается и вызовов SendText/SendBuf-методов - в неблок.режиме анализ результатов их вызовов обязателен.

← →
sergeyst © (2007-07-31 11:15) [46]

> Evgeny V © (31.07.07 08:13) [43]

Зачем так безаппеляционно? Оппоненту надо было оставить шанс поспорить, а теперь он потерян... А жаль, было очень интересно!

← →
SlymRO © (2007-07-31 11:50) [47]

sergeyst © (31.07.07 11:15) [46]
чемто напомнило анекдот про то как два кавбоя бесплатно дерьма наелись

← →
Evgeny V © (2007-07-31 14:27) [48]

I>
> sergeyst © (31.07.07 11:15) [46]

потому и безапеляционно, что не люблю когда единственный аргумент хамство.

Если тебе интересно, то расскажу.

> Сергей М. © (30.07.07 10:17) [6]
> Цитата из Winsock API Reference (ioctlsocket):
>
> If s is stream oriented (for example, type SOCK_STREAM),
> FIONREAD returns an amount of data which can be read in
> a single recv; this may or may not be the same as the total
> amount of data queued on the socket

Эта цитата на которую ссылался как на якорь Сергей М. говорит только об одном . Что FIONREAD для потокоориентированнхы сокетов возвращает количество данных, которые могут быть считаны одиночным вызовом recv. И это число может быть равно или не равно общему числу данных в очереди (буфере -мне удобней так называть) сокета. FIONREAD вызыватеся в ReceiveBuf, если параметром Count передать -1.

То есть отсюда мы видим, что есть два числа характеризующих очередь сокета. Они равны, или нет, это возвращаемое FIONREAD и общее число данных. Пока все - оснований делать вывод о том, что ReceiveBuf с Count=FIONREAD вернет больше Сount или меньше или равно нет. Интересно, какое из чисел больше - общее число байт в очереди (хотя название вроде и говорит за себя) или возвращаемое FIONREAD (ReceiveLength). Для этого читаем про FIONREAD подробнее "FIONREAD still returns the amount of pending data in the network buffer, however, the amount that can actually be read in a single call to the recv function is limited to the data size written in the send or sendto function call. "
FIONREAD возвращает число ожидающих в сетевом буфере данных, которые могут быть считаны одиночным вызовом функции recv, ограниченной размером данных, которые могут быть записаны Send или SendTo. тут надо понимать, что в буфере сокета данные могут накапливаться. Если не было вызовов recv, но было несколько Send на наш сокет, то общее число данных в буфере и есть сумма пришедших данных от этих Send. Но есть ограничение на размер данных - размер фрейма, который можно передать одним вызовом Send. Это же ограничение и есть максимально возможное число, возвращаемое FIONREAD, то есть за раз мы не можем считать recv больше этого числа, хотя общее число данных в буфере может быть больше. То есть нам надо сделать несколько чтений

Таким образом получаем, что FIONREAD <= общее число данных в буфере.

Теперь читаем про recv
"For connection-oriented sockets (type SOCK_STREAM for example), calling recv will return as much data as is currently available—up to the size of the buffer specified."
Для ориентированных на соединение сокетов ( например SOCK_STREAM ) вызов recv возвращает столько данных, сколько сейчас доступно, но не более верхней границы буфера. Все - этого достаточно.
Вызов i:=ReceiveBuf(buf[0],Count) может дать I < Count, если мы задали какой-то Count, больший чем число данных в буфере (очереди), доступных для одиночного вызова Recv или данных там нет, или просто меньше Count.

Но если мы сделали Count:=ReceiveLength; - получили число данных доступных - действительно доступных в буфере для одиночного вызова Recv (FIONREAD ), то при i:=ReceiveBuf(buf[0],Count) мы получим I=COUNT ("return as much data as is currently available"). Возможен вариант, когда I=0 и не равен COUNT, или -1 -это при gracefully (бережном) закрытии сокета "If the connection has been gracefully closed, the return value is zero", или -1 (SOCKET_ERROR), если в буфере не было данных для чтения при неблокирующей работе сокета. Других вариантов в документации нет(уточню -я не видел). По моему опыту работы с сокетами - это подтверждается, не было так, что бы в результате I:=3, а COUNT был 4 (при условии, что Сount=ReceiveLength). А I > Count - это вообще невозможно. Что касается кода от борланда ReceiveText - я не знаю почему такой, как вариант, они просто освобождают буфер, если ReceiveBuf вернул 0. Я могу предложить такую версию или версию перестраховки. Чужая голова потемки. Вот в общем и все из-за чего был спор.

← →
Сергей М. © (2007-07-31 14:36) [49]

> По моему опыту работы с сокетами - это подтверждается, не
> было так, что бы в результате I:=3, а COUNT был 4

Значит твой опыт круче опыта Борланда)
И по этому случаю место коду ReceiveText - свалка)

> I > Count - это вообще невозможно

Да неужели ?
А я только это и пытался доказать)))))))

← →
Evgeny V © (2007-07-31 14:45) [50]

> Сергей М. © (31.07.07 14:36) [49]
> Сколько queued, столько и вернет

Ваши слова? А про то, что надо понимать что такое очередь ваш вопрос? А про то, что в очереди может быть больше данных, чем ReceiveLength вы знаете?
Впрочем извинияюсь, опять начинается бодяга, а мне не охото это продолжать.

Про борланд не скажу, не считаю себя сильным программистом, но свой хлеб вполне нормально отрабатываю. Но вполне допускаю, что могут быть и те варианты которые я назвал.

← →
Сергей М. © (2007-07-31 14:49) [51]

> не считаю себя сильным программистом

У тебя есть шанс стать более сильным, изучив TCP-протокол и виндовый TCP-стек в части его реализации.

← →
Сергей М. © (2007-07-31 14:51) [52]

> Evgeny V

Ну а вот это

Sleep(1000);// жду когда приедет побольше

как было галиматьей, так ей и остается)

← →
Сергей М. © (2007-07-31 15:49) [53]

> Evgeny V

Где ты, чудо ?

Парируй).. По поводу "галиматьи" хотя бы) ...

← →
sergeyst © (2007-07-31 15:52) [54]

Предлагаю устроить всеобщее голосование: кто прав и кто круче!

← →
Сергей М. © (2007-07-31 15:55) [55]

> Сергей М. © (31.07.07 15:55) [55]

Вот ты и проголосовал. Что ж, не могу не согласиться. Непредвзятость хорошее качество.

> Ой врешь же !)

Ну, а откуда тогда такие резкие выпады?

Удалено модератором
Примечание: Отдохни недельку, поучи русский язык

Запись буфера помогите? Найти похожие ветки