информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetВсе любят медСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
1.2 - это именно скорость отсылки без учета потерь (удп не... 26.12.04 12:22  Число просмотров: 2441
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 26.12.04 12:29  Количество правок: 1
<"чистая" ссылка>
1.2 - это именно скорость отсылки без учета потерь (удп не гарантирует доставку пакетов)?
Возможно дело тут и в самой винде - всетаки если слать через тсп то совершается меньше вызовов юзер-кернел т.к. можно засунуть в единичный сенд большой блок данных который затем нарежеться по пакетам непосредственно в ядре (в tcpip.sys). Да и в буфер сетевухи они могут передаваться за одну транзакцию по шине. Вобщем разные тонкости тут могут быть). Как кстати дело обстоит с загрузкой процессора при посылке по УДП с максимальной скоростью?
<programming>
UDP vs TCP 25.12.04 22:55  
Автор: Gorynich Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Скажите, пожалуйста, кто знает.

Написал прогу для многоадресной рассылки файла, точнее две - "отправителя" и "приемника". Проверить в сети на нескольких машинах нет пока возможности, поэтому тестил локально. Так вот, скорость отсылки составляет всего ~700-800 Kbps. На холостом ходу, т.е. без "приемника" - 1.2 Mbps.
Такая же байда и с broadcast.
Даные передаю по 1469 Байт - размер полезных данных кадра Ethernet - наибольшая эффективность.
Для сравнения написал клиент и сервер на TCP. Тестил локально - 5-6 Mbps.
В чем причина? Как с этим бороться?
UDP vs TCP - source code 26.12.04 12:55  
Автор: Gorynich Статус: Незарегистрированный пользователь
Отредактировано 26.12.04 12:58  Количество правок: 2
<"чистая" ссылка>
Загрузка процессора ~30%, ядро ~28 %.

#include "stdafx.h"
#include <stdio.h>
#include "winsock2.h"
#include "Ws2tcpip.h"

int _tmain(int argc, _TCHAR* argv[])
{
 
  WSADATA wsaData;
  SOCKET SendSocket;
  sockaddr_in RecvAddr, source_sin;
 
  char SendBuf[1469];
  int BufLen = 1469;

  int iOptVal = 64;
  int iOptLen = sizeof(int);
  int ret, nLeft;
  DWORD nBytesRead, nBytesToRead = 1024;

  WSAStartup(MAKEWORD(2,2), &wsaData);

  SendSocket = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

  source_sin.sin_family = AF_INET;
  source_sin.sin_port = htons (0);
  source_sin.sin_addr.s_addr = htonl (INADDR_ANY);

  bind (SendSocket, (SOCKADDR*) &source_sin, sizeof (source_sin));

  setsockopt (SendSocket, IPPROTO_IP, IP_MULTICAST_TTL, (char*)&iOptVal, iOptLen);

  RecvAddr.sin_family = AF_INET;
  RecvAddr.sin_port = htons(4567);
  RecvAddr.sin_addr.s_addr = inet_addr ("225.6.7.8");

  HANDLE hFile;
  hFile = CreateFile("D:\\Games\\Far Cry\\FCData\\Textures.pak", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
  nLeft = GetFileSize(hFile, NULL);
  nBytesRead = htonl(nLeft);
  nBytesToRead = 4;
  ret = sendto(SendSocket, 
		(char*)&nBytesRead, 
		nBytesToRead, 
		0, 
		(SOCKADDR *) &RecvAddr, 
		sizeof(RecvAddr));

  while (nLeft > 0) 
  {
	  ReadFile(hFile, SendBuf, nBytesToRead, &nBytesRead, NULL) ;
	  ret = sendto(SendSocket, 
		SendBuf, 
		BufLen, 
		0, 
		(SOCKADDR *) &RecvAddr, 
		sizeof(RecvAddr));
	  nLeft -= ret;
  }
  CloseHandle(hFile);

  shutdown(SendSocket, 0x01);
  closesocket(SendSocket);

  printf("Exiting.\n");
  WSACleanup();
 
}

---
[C++] UDP vs TCP - source code 12.01.05 18:02  
Автор: SAD Radical Статус: Незарегистрированный пользователь
<"чистая" ссылка>

>
> while (nLeft > 0)
> {
> ReadFile(hFile, SendBuf, nBytesToRead,
> &nBytesRead, NULL) ;
> ret = sendto(SendSocket,
> SendBuf,
> BufLen,
> 0,
> (SOCKADDR *) &RecvAddr,
> sizeof(RecvAddr));
> nLeft -= ret;
> }
Помоему лучше считывать данные в большой буфер и его скармливать в sendto далее смещать адрдес буфера на размер переданных данных. Это вопервых сократит вызовы ReadFile на порядок и позволит стеку самому выбирать размер отправляемого в сеть сегмента.
ReadFile-памаметр nBytesToRead равен 4. Т.е. у тя читаецца... 26.12.04 13:14  
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 26.12.04 13:19  Количество правок: 1
<"чистая" ссылка>
> nLeft = GetFileSize(hFile, NULL);
> nBytesRead = htonl(nLeft);
> nBytesToRead = 4;
> ret = sendto(SendSocket,
> (char*)&nBytesRead,
> nBytesToRead,
> 0,
> (SOCKADDR *) &RecvAddr,
> sizeof(RecvAddr));
>
> while (nLeft > 0)
> {
> ReadFile(hFile, SendBuf, nBytesToRead,
> &nBytesRead, NULL) ;
> ret = sendto(SendSocket,
> SendBuf,
> BufLen,
> 0,
> (SOCKADDR *) &RecvAddr,
> sizeof(RecvAddr));
> nLeft -= ret;
> }
> CloseHandle(hFile);
ReadFile-памаметр nBytesToRead равен 4. Т.е. у тя читаецца по 4 байта с файла для каждой посылкой. А шлеться в сеть мусор.. Ну это ладно - на скорость не влияет, учитывая что мусор шлеться размер файла/размер буфера раз Ж)
Лучше бы добавить флаг FILE_FLAG_SEQUENTIAL_SCAN в создании файла..
Размер блока данных лучше определять через getsockopt(..SO_MAX_MSG_SIZE..)
А какая скорость при посылке на на мультикаст а на существующий в сети ип?
С nBytesToRead провтыкал - оптимизировал :D. 26.12.04 13:54  
Автор: Gorynich Статус: Незарегистрированный пользователь
Отредактировано 26.12.04 14:08  Количество правок: 1
<"чистая" ссылка>
> ReadFile-памаметр nBytesToRead равен 4. Т.е. у тя читаецца
> по 4 байта с файла для каждой посылкой. А шлеться в сеть
> мусор.. Ну это ладно - на скорость не влияет, учитывая что
> мусор шлеться размер файла/размер буфера раз Ж)

С nBytesToRead провтыкал - оптимизировал :D.

> Размер блока данных лучше определять через
> getsockopt(..SO_MAX_MSG_SIZE..)

65507. Но при таком размере скорость составляет 26 Kbps.

> А какая скорость при посылке не на мультикаст а на
> существующий в сети ип?

~1.7 Mbps.
1.2 - это именно скорость отсылки без учета потерь (удп не... 26.12.04 12:22  
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 26.12.04 12:29  Количество правок: 1
<"чистая" ссылка>
1.2 - это именно скорость отсылки без учета потерь (удп не гарантирует доставку пакетов)?
Возможно дело тут и в самой винде - всетаки если слать через тсп то совершается меньше вызовов юзер-кернел т.к. можно засунуть в единичный сенд большой блок данных который затем нарежеться по пакетам непосредственно в ядре (в tcpip.sys). Да и в буфер сетевухи они могут передаваться за одну транзакцию по шине. Вобщем разные тонкости тут могут быть). Как кстати дело обстоит с загрузкой процессора при посылке по УДП с максимальной скоростью?
Если ты перед отправкой пакета каждый раз делаешь socket() -... 26.12.04 11:55  
Автор: YYY Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Скажите, пожалуйста, кто знает.
>
> Написал прогу для многоадресной рассылки файла, точнее две
> - "отправителя" и "приемника". Проверить в сети на
> нескольких машинах нет пока возможности, поэтому тестил
> локально. Так вот, скорость отсылки составляет всего
> ~700-800 Kbps. На холостом ходу, т.е. без "приемника" - 1.2
> Mbps.
> Такая же байда и с broadcast.

Если ты перед отправкой пакета каждый раз делаешь socket() - то из-за этого (это довольно медленная операция), если нет, то не знаю.. код давай.

> Даные передаю по 1469 Байт - размер полезных данных кадра
> Ethernet - наибольшая эффективность.

а вот и нет (см. ниже)

> Для сравнения написал клиент и сервер на TCP. Тестил
> локально - 5-6 Mbps.

а у меня через сетку 11 :)
поигравшись я пришел к тому, что для (нашей, 100М) локалки буфер в 4К дает наибольшую скорось, дальнейишее увеличение не влияет
Не надо путать размер ethernet фрейма который влияет на... 26.12.04 12:16  
Автор: Killer{R} <Dmitry> Статус: Elderman
<"чистая" ссылка>
> а у меня через сетку 11 :)
> поигравшись я пришел к тому, что для (нашей, 100М) локалки
> буфер в 4К дает наибольшую скорось, дальнейишее увеличение
> не влияет
Не надо путать размер ethernet фрейма который влияет на максимальный размер датаграммы передаваемой через удп сокет и размер буфера передаваемого в единичный send потоко-ориентированного тсп сокета.
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach