Подсчет информации переданной сокетом

← →
alexta (2002-07-11 02:52) [0]

Привет, знатоки!

Может кто сталкивался. Как подсчитать количество информации переданной сокетом за определенное время? С подсчетом входящей - проблем нет, а вот с исходящей...

С уважением, Алексей.

← →
Malder (2002-07-12 16:50) [1]

Поделись, как ты подсчитываешь входящий траффик ?

← →
Malder (2002-07-15 13:38) [2]

Ау.

← →
Pingo (2002-07-15 13:50) [3]

>> Поделись, как ты подсчитываешь входящий траффик ?

← →
alexta (2002-07-16 16:23) [4]

Сорри за ожидание.

Это легко.
ClientRead - навешен на OnRead Client-а, OnTimer - на OnTimer Timer-а.

var
InputTraffic: integer;
InfoCounter: integer;
Timer: TTimer;
Client: TClientSocket;

procedure ClientRead(Sender: TObject; Socket: TCustomWinSocket);
var
Buf: PChar;
len: integer;
begin
len:=Socket.ReceiveLength;
GetMem(Buf,len);
len:=Socket.ReceiveBuf(Buf,len);
inc(InfoCounter);

//----------
// your code
//----------

FreeMem(Buf);
end;

procedure OnTimer(Sender: TObject);
begin
InputTraffic:=InfoCounter div Timer.Interval;
InfoCounter:=0;
end;

← →
alexta (2002-07-16 16:41) [5]

Опечатка получилась. В 4-ой строке ClientRead нужно:
inc(InfoCounter,len);

← →
Digitman (2002-07-16 17:30) [6]

Ну так - по аналогии и исходящий считай :

CurrentlyBytesSent:=Socket.SendBuf(Buf, BytesToSend);
Inc(TotalBytesSent, CurrentlyBytesSent);

И в чем проблема ?

← →
Digitman (2002-07-16 17:34) [7]

← →
Song (2002-07-16 18:09) [8]

GetIPStatistics()

← →
alexta (2002-07-16 20:09) [9]

>2 Digitman
Такой вариант не пройдет. У меня nonblocking сокет. Поэтому SendBuf возвращает количество байтов поставленных в очередь на отправку (во внутренний буфер сокета). К реально отправленым - не имеет никакого отношения.

← →
alexta (2002-07-16 20:13) [10]

> Song
Не катит. GetIPStatistics - дает информацию по текущему IP. То есть она вывалит мне общий исходящий трафик, а мне нужно именно конкретного сокета.

← →
Digitman (2002-07-17 08:46) [11]

>alexta

Буферизация работает в любом случае : и в блок. режиме и в неблокирующем.

Если тебя смущает сей факт, то обрати внимание на событие OnWrite(). Это событие в неблок.режиме фиксирует факт освобождения буфера и это вполне можно использовать, интерпретируя как сигнал о фактической передаче данных при одном или более предыдущих вызовах send().

Вот детальное описание его (события) "потрохов" в том же хэлпе :

The FD_WRITE network event is handled slightly differently. An FD_WRITE network event is recorded when a socket is first connected with connect/WSAConnect or accepted with accept/WSAAccept, and then after a send fails with WSAEWOULDBLOCK and buffer space becomes available. Therefore, an application can assume that sends are possible starting from the first FD_WRITE network event setting and lasting until a send returns WSAEWOULDBLOCK. After such a failure the application will find out that sends are again possible when an FD_WRITE network event is recorded and the associated event object is set.

← →
alexta (2002-07-17 15:55) [12]

> Digitman

Меня смущает не буферизация, а время возникновения OnWrite. Да, оно возникает после освобождения буфера (это и есть плохо). Теоретически повесив секундомер на OnWrite и счетчик на SendBuf можно подсчитать трафик. НО! Если ты передаеш данные большого объема, то возникновение события произойдет очень поздно. И получится, что ты получил общий трафик сокета за n-ое время - что не есть хорошо. Я бы хотел определять трафик за заданое время. Не знаеш, может можно как-то достучаться хотя-бы до буфера сокета? Тогда используя передачу через поток можно было-бы определить какой кусок уже передан.

← →
Digitman (2002-07-17 17:23) [13]

Я не думаю, что это так уж страшно и коряво - за заданное время подсчитать фактический объем отправленных дейтаграмм, подсчитав как результат усредненный траффик за период. Ведь и входящий траффик (о подсчете которого ты как бы не волнуешься) - тоже усредненный получается ! Те же M чтений по N байт за время T...

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

Но, если уж тебя потянуло на более низкий уровень, "копать" нужно в библиотеке WS2HELP.DLL, это - посредник между WinsockAPI и ядром , она ближе к файловым операциям и run-time-нотификациям событий в сетевом транспорте.

← →
alexta (2002-07-17 20:07) [14]

OnRead отличается от OnWrite тем, что это событие возникает при ЧАСТИЧНОМ наполнении буфера (точность возрастает, событие OnRead более дифференциировано). Максимальный объем принятых данных при OnRead у меня был около 12 Кб. OnWrite же возникало только после полной передачи буфера (у меня было например 1 Мб и больше).
За Ws2help.dll - спасибо. Попробую что-то нарыть.

← →
Digitman (2002-07-18 09:30) [15]

>alexta

Не совсем так.

FD_READ возникает при непустом буфере гнезда-приемника.

Ничто не мешает тебе при FD_READ читать буфер с ДОСТУПНЫМ содержимым переданного за один прием потока, например, в 3 кб за 3 приема по 1 кб в каждом. Тогда, если в обработчике FD_READ считывать очередные фрагменты потока по 1 кб, всего возникнет не менее 3-х событий FD_READ. Прими это во внимание.

Подсчет информации переданной сокетом Найти похожие ветки