Занимаюсь разработкой класса инкапсулирующего возможности winsocket'ов. Нужно добиться подобной абстракции:
Псевдокод:

Код

WPsocket wpsock(IP, PORT); wpsock >> buffer; wpsock << buffer;

Где >> и << операторы отправки и примема данных соотвественно.
То есть мне надо достичь потоковой гибкости и простоты.
Просто мысли разбегаются... вообще как примерно должен выглядеть такой класс ? Если можно, то в общих чертах.

En_t_end
В общих чертах так:
создаеш класс
перегружаеш << операторы для него, в которых делаеш send по длине параметра (для данных переменной длины надо добавить какойто разделитель
перегружаеш >> опрераторы в которых делаеш recv пока не будет данных нужной длинны

Mad

Цитата(Mad @ 15.10.2005, 22:05)

опрераторы в которых делаеш recv пока не будет данных нужной длинны

В смысле ?... это что перебор получается ?
Добавлено @ 18:17

Цитата(Mad @ 15.10.2005, 22:05)

перегружаеш >> опрераторы в которых делаеш recv пока не будет данных нужной длинны

В том-то и проблема, что я не знаю какие данные должны прийти. Вернее я то знаю, обьект класса не знает.
Есть мысля по этому поводу...

Код

wpsock.SetDataSize(HOW_LONG_DATA); wpsock >> buffer;

То есть так можно будет скрыть от программиста цикл приема данных по частям.

Цитата(En_t_end @ 15.10.2005, 17:14)

это что перебор получается

нет, например

Код

public operator >> (int& val) {     char buff[4];     recv(sock, buff, 4, 0);     val = *(int*)buff; }

также и для других типов данных(только надо еще добавить проверку саколько принято )

Mad
Есть ещё проблема с размерами сетевых пакетов для протокола TCP/IP.
Нужно каким-то образом точно разбить данные(скорее всего придется узнавать максимально возможный размер пакета, кстати как это можно сделать, как можно переносимей для винды) и отправить их по средством << настолько чисто, так чтобы для программиста, пользующегося обьектом, все это выглядело в одной операции.

Цитата(En_t_end @ 15.10.2005, 17:14)

В том-то и проблема, что я не знаю какие данные должны прийти. Вернее я то знаю, обьект класса не знает.

Если в приведенном мной коде добавить контроль поступления

Код

char buff[4]; int received = 0; while(received < 4) {     int i = recv(sock, buff+received, 4-received, 0);     received += i; }

тогда у тебя оператор выйдет только после получения 4 байтов (т.е полно int как и нужно было )

Цитата(En_t_end @ 15.10.2005, 17:22)

Нужно каким-то образом точно разбить данные

а зачем ? TCP и так дает полный поток. Если в самом операторе ждать получения полных данных, то уже без разницы как там TCP этиданный разбила (тем более, что они могут быть дополнительно разбиты при пересылке роутером)

Mad
ОК... спасибо... будем работать
Добавлено @ 18:38

Цитата(Mad @ 15.10.2005, 22:30)

а зачем ? TCP и так дает полный поток.

Просто я сам был свидетелем работы одной программы сделанной для отмазки. Там наблюдался глюк с приемом и отправкой большого обьема данных. Получалось, что данные приходили либо не полностью, либо вовсе не приходили.
Мое беспокойство было вызванно именно по поводу отправки... система сама разбивает данные ?
ЗЫ просто сам я кроме больше чем 100 байт через TCP/IP не передовал.

En_t_end
Что-то подобное реализовывал 2 года назад.
Можно сделать, что данные в буфер кладутся в течении 50 мсек, а потом отсылаются. И так же контроль буфера, т.е. если буфер полон - данные отсылаются.
Также можно ввести идентификаторы:

Код

class CBaseSock{ ... public:   enum Ident{ START, FLUSH, SIZE, DATA, STOP }; ...   template<class T> CBaseSock& operator << (T tData)   {       if ( isChild(tData) )      {       ...       // Если tData - тип Ident::SIZE, то значит в tData придет размер данных      }      ...   } ... };

Цитата(En_t_end @ 15.10.2005, 17:33)

Получалось, что данные приходили либо не полностью, либо вовсе не приходили.

При отправке (вызове send) возвращаеться сколько данных помещенно в буффер, с контролем получаеться так

Код

void SendData(char *buff, int len) {     int sended = 0;     while(sended < len)     {         int i=send(sock, buff+sended, len-sended, 0);         sended += i;     } }

так я максимум до 20Мб пересылал

Mad
Thks!
bel_nikita
Очень интересное предложение, попробую реализовать.

bel_nikita
Насколько я понимаю, если расширить ваш совет, то можно будет добиться следующей абстракции:

Код

wpsock << DATA_SIZE << buffer;

Цитата(En_t_end @ 16.10.2005, 07:44)

wpsock << DATA_SIZE << buffer;

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

TCP предоставляет только транспорт, протокол обменна клиент<->сервер(протокол высокого уровня) надо разрабатывать самому

En_t_end

Цитата

Насколько я понимаю, если расширить ваш совет, то можно будет добиться следующей абстракции

Да, именно так.

Код

wpsock << DATA_SIZE << LenghtBuffer << pBuffer;

Хотя это уже разновидности реализации на усмотрение разработчика.
Вообще, хорошо бы разбить все на уровни: транспортный, пакетный и пользовательский. Транспортный(физический) только непостредственно прием/передача. Пакетный - создание пакетов для отсылки или распаковка при приеме. Пользовательский или сервисный уровень - это и есть перегрузка операторов << >>.
Так же хорошо(как и говорил выше) сделать отдельный тред на отсылку, или другими словами таймер. Как только первая порция(назавем так) данных поступипа - включается таймер и данные кладуться в буфер. Как только прошло допустим 50 мсек или в буфере нет уже места - данные отсылаются. Ну и конечно, предусмотреть идентификатор FLUSH - отсылка/очистка буфера, т.е. данные сразу отсылаются без таймера.
Ну и конечно, нужно знать для чего это все нужно? Если это файлы, то тут лучше использовать FTP. Если какие-то большие объемы информации, то обязательно нужно реализовывать пакетный уровень. Ведь в TCP первый высланный пакет может прийти последним

bel_nikita

Цитата(bel_nikita @ 16.10.2005, 22:56)

Ведь в TCP первый высланный пакет может прийти последним

То есть надеется на последовательное заполнение буфера в цикле recv не стоит ?
Добавлено @ 11:10
Пока делаю так...
Создал класс родитель LSocket:

Код

class LSocket {};

И два потомка:

Код

class LSockAccept : public LSocket {}; class LSockJoin : public LSocket {};

Теперь реализую в потомке Accept сокет переводящийся в режим ожидания подключения.
А для Join - организацую подключения со стороны клиента.

Подумываю организовать специальный протокол обмена. То есть обеспечить автоматическое выделение канала FTP для передачи файлов, если будет получен соотвествующий запрос по TCP.

Цитата(En_t_end @ 17.10.2005, 10:01)

Ведь в TCP первый высланный пакет может прийти последним

откуда такая инфа ?