WinSock и 100%-ная загрузка CPU

Добрый день!
Кто-нибудь знает, как снизить загрузку проца при длительном приеме (передаче) данных через WinSock, а то у меня уже при 8-ти работающих экземплярах Winsock'а, связанных с восемью разными компами (я пытаюсь сделать один распределенный алгоритм...) процессор загружен на 100% (!) и все восемь экземпляров начинают работать с периодическими остановками в приеме (передаче) данных. Причем, сам объем передаваемых данных невелик: клиент отсылает строку (из двух символов) серверу, а сервер, приняв эту строку, выполняет некоторое действие над ней и отсылает модифицированную строку (2 символа) клиенту, затем в цикле процесс повторяется снова, но уже со строкой других данных. Связь клиента и сервера должна поддерживаться постоянно.
Пробовал экспериментировать и вместо OCX-компонента WinSock'а использовал API - результат тот-же! Может это такая особенность VB6 пожирать ресурсы при работе WinSock? Для сравнения: всем известный RemoteAdministrator (версии 2.1) при передаче целого экрана (!) удаленной машины с частотой сканирования 100 раз в секунду при 65536 цветах съедает всего лишь 3-5% ресурсов проца. Если кто знает, как с этим бороться - подскажите!!!

0

попробуй использовать udp-протокол

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

0

Ну, реализуй работу с сетью не на VB. Передать пару байт во внешнюю функцию - не проблема. К тому же, желательно использовать мультитрединг.

Посмотри ссылочку:
http://www.vbnet.ru/sample/sampledownload.asp?id=288

Не знаю - то ли это, что тебе нужно, но на всякий случай

За ссылку - спасибо, но как оказалось, там элементарный пример.
Насчет MultiThreading - уже пробовал использовать (через ActiveX EXE), но внутри каждой создаваемого потока сидит ТОТ ЖЕ тормозной WinSock и по-прежнему тормозит!!! Замену до сих пор ему не нашел.

Кто еще чего может посоветовать??? Где только не смотрел, ничего пока не нахожу! Неужели никто не сталкивался с таким эффектом у WinSock'а?

Кстати, кажись дельная идея Messir насчет реализации работы с сетью не на VB... Может у кого есть ссылки, предложения. Буду весьма признателен за совет!

0

Мультитрединг через ActiveX EXE?! )) ЛОЛ!!!
ActiveX - это вообще в данном случае тормозная лажа, применение которой не оправдано. Поэтому забей на него в принципе. Реализую мультитрединг через CreateThread, в процедуре треда юзай API для работы с сетью.

Да, действительно.
Тоже столкнулся с проблемой длительной передачи данных через Winsock
Как ни странно, но теряю данные в сети, а прога очень чувствительна к порядку переданной информации. Как решить ? Думаю, нужно пробовать создать два соединения. Одно передает данные, второе в качестве контроля ИМХО.

0

Приветствую тебя, PMSSpy !

Твоя проблема с потерей данных в сети, как мне кажется, немного проще, чем моя. Попробую тебе предложить два варианта:
ВАРИАНТ ПЕРВЫЙ.
шаг1: клиент передает серверу блок твоих данных, причем (ВАЖНО!) в конец этого блока дописывает нечто вроде идентификатора данного блока (в качестве идентификатора я использую число типа Long, начинающееся с префикса (символа S), означающего источник блока данных, т.е. сервер), причем значение идентификатора у каждого следующего передаваемого блока будет увеличиваться на 1. Этот идентификатор сохраняется в отдельной переменной (до шага 3).
шаг2: сервер, приняв ЭТОТ блок данных, берет его идентификатор и обратно клиенту отправляет нечто вроде подтверждения, в котором содержится идентификатор только что принятого блока.
шаг 3: клиент, получив это подтверждение, берет из него идентификатор и сравнивает его с отправленным идентификатором и если они совпадают, то значит, что блок данных ДОШЕЛ НОРМАЛЬНО и можно отправлять следующий блок!
Такая процедура гарантирует сохранность отправленных данных, но важно, чтобы идентификатор отправляемого блока никогда больше не повторялся, т.е. был уникальным.

ВАРИАНТ ВТОРОЙ.
Чтобы данные не терялись, можно перед отправкой блока данных проверять состояние WinSock'а: если WinSock.State=7, то отправлять можно. Фрагмент кода:

Do While (Not WinSock.State=7)
DoEvents
Loop
WinSock.SendData БлокДанных

Но такой метод имеет недостатки, о которых здесь уже говорилось: сильная загрузка проца из-за цикла Do...Loop

Удачи!

0

Нет, господа. Что-то вы не так делаете...
Поскольку _гарантированная_ доставка данных задожена в протокол TCP изначально. И, например, у меня ни разу не возникало ситуации, чтобы пакеты терялись (выдергивание сетевого кабеля в момент передачи не считается... )
посему рекомендации:
1. Отказаться от использования компонента WinSock вообще
2. Если работа действительно длительная, то разумнее, мне кажется, было бы выделить работу с сетью отдельной службой
3. В любом случае, реализовывать работу с сетью лучше не на VB.

Два вышеприведенных варианта мною были даны PMSSpy из-за того, что протокол-то конкретно не был указан!
Ну а если речь пойдет про TCP, то действительно, это протокол с гарантированной доставкой, а блоки данных могут теряться из-за того, что отправка блока от клиента происходит тогда, когда сервер еще не успел завершить прием предыдущего блока. И чтобы исключить это, мне кажется, надежнее всего делать подтверждение приема блока данных сервером, что и было описано мной...

Но основной-то вопрос не решен - почему полностью загружается проц?
Мною уже были перепробованы следующие решения:
1) отказ от использования WinSock'а и переход на API. Результат тот же.
2) работа с сетью выполнялась в отдельном потоке. Результат тот же.
3) полное исключение использования циклов Do...Loop и переход на событийное управление.

Если кто порекомендует, где найти готовую библиотеку или OCX, написанные на C, C++, то думаю, это единственное, что осталось не проверенным. Если знаете где, киньте ссылку!

0

Смотря что подразумевать под 'готовой библиотекой'. Вообще, если прога маленькая и преобразования указанных 'двух байт' достаточно простые, я бы вообще отказался от использования VB. В данном случае лучше было бы писать на асме или сях...

У меня событийная схема:

схема пакета данных
Prog_ID (string*ZZZ)
Mode_ID (byte)
From_ID (dword)
To_ID (dword)
Data (255 bytes)
End_of_block_ID = chr(0) или chr(1) по случаю

т.е. стоиться все так:
приходит пакет (произвольный)
копируем его в переменную
проверяем, есть в переменной Prog_ID ?
Нет -> выход из процедуры
Да! -> выделяем из переменной пакет и направляем на обработку другой процедуре.
Процедура обрабатывает режим передачи (byte Mode_ID) и в зависимости от него узнает, что за данные пришли, от кого и кому (тоже сравнивается)

Кстати, в качестве окончания используется chr(0) иначе chr(1) означает, что передача данныых еще не завершена и будет продолжена.

Вот где-то здесь теряются данные на клиенте. Подскажите, или вам сам код выложить?

0

Про 'два байта' - это, конечно, сильное упрощение. В реальности под двумя байтами понимается блок данных длиной от 32 до 64 байт (что тоже не слишком много). Но дело даже не в этом, а в том, что когда их передача начинает происходить более-менее НЕПРЕРЫВНО, то исчерпываются все ресурсы проца. И это только ОДИН экземпляр WinSock!
А если этих экземпляров будет штук десять?
У меня комп PIII-733/ОЗУ 512МБт, сеть 100МБит и уже при пяти запущенных WinSock'ах, связанных с пятью разными машинами, в режиме НЕПРЕРЫВНОЙ передачи (БЕЗ ЦИКЛОВ!) все пять WinSock'ов начинают бултыхаться: один вроде бы передает, второй снижает скорость, третий молчит; потом первый затыкается, второй передает по байту в несколько секунд и т.д. и т.п! О запуске новых WinSock'ов и речи нет: грузятся минуты три!!! А затем начинают работать все вместе так, как и первые пять. Налицо ситуация, когда НЕТ СВОБОДНЫХ РЕСУРСОВ ПРОЦА! Их забирает (или забирают) работающие WinSock'и!
Код нормальный, циклы отсутствуют: вместо цикла я использую событие DataArrival для того, чтобы передать следующий байт, когда придет блок-подтверждение того, что все дошло нормально (пример см. выше) и только после этого отправляю следующий байт (или байты, если быть точнее). Использую событие и циклы сами собой отпадают.
В моей ситуации сеть загружена по-минимуму, но этот WinSock...

Последнее остается: работу с сетью делать не на VB. Но асма и С не знаю, поэтому прошу что-нибудь подсказать из готовых модулей/библиотек/компонент. Чтобы можно было подключить к проекту и не морочить голову.
Кстати, пробовал использовать Pipes, пример с которыми есть на VBrussian. Работает в пределах локальной машиы (сервера висят на разных портах) вроде бы хорошо, но и тут облом: по сети не коннектится, хотя у предложенного компонента есть свойство ServerName, которое позволяет читать или устанавливать имя сервера, на котором открыта Pipe, с которой нужно установить соединение. В общем, халтура. Хотя в MSDN уверяют, что мол только замените '.' на имя удаленной машины и все будет OK!

0

Попробуй выложить код, поглядим

0

видел где-то в сети VB-проектик 'MultiDownloader' (или что-то близко к этому): там сделан многопоточный загрузчик с FTP, 'a la FlashGet'. вроде работала эта штука нормально... может, вам стоить найти её и посмотреть, как она сделана? - благо проект идёт с исходниками.
(увы, рад бы помочь, да не сохранил ни исходники этого проекта, ни ссылку на его загрузку ( )

участникам переписки сбросил файл с клиент-сервером на почту.
иным - ссылку даю http://www.pmsspy82.narod.ru/client-server.zip

0

Похоже, эта ссылка - несуществующая.

0

Неправильно вы гоните на winsock!
он круче всех api! )

У меня программа (Network Communicator, www.communicator.net.ua)
работает одновременно с 2-36 экземплярами winsock и не тормозит вообще! Даже броадкаст используется!

Главное правило везде использовать проверку на winsock1.state = 7
и везде вставлять doevents.
Последняя команда делает паузу где-то от 70 до 100 милисек и позволяет ОС отвлечься на другие процессы.

Особенно важно юзать ее в цикле do ... loop и других.

to x-jek: скинь мне свой е-мейл, я тебе вышлю свой проект.
вся инфа с моем профиле

0