> ну чего обижаться...Мы же объясняли, что не тот протокол.
> ..Или девушка ждала исходный программы ее мечты?пускай напишет,
>  что она хотела...


Как передать по протоколу TCP скриншот - не составляет проблемы. Почему выбран был именно UDP? объясняю:

1. Для локальной сети не думаю, что это принципиально важно, хотя может быть и важно. Дело в том, что TCP - довольно медленный по сравнению с UDP. И если все таки передавать по TCP - возникает только один вопрос: Зачем лишние проверки и подтверждения доставленна ли картинка или нет. Видь при этом мы теряем в скорости...

2. Сначала моя программа была ориентирована на Tcp, но в связи с несколькими возникшимся проблемами, а именно: низкая скорость передачи, мерцание при смене картинки в image, и таже проблема, о которой я писала в самом первом сообщении с постоянным уменьшением картинки, если отображать принятую картинку в image, а потом вдруг изменить размер image...

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

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

По поводу ClientSocket и ServerSocket, что Вы  их обнаружили у меня в коде, то это связанно с другими функциями моей программы. Хотя наверняка можно было и без этих компонент обойтись спокойно, еще раз повторюсь - сначала программа делалась именно для TCP. Зачем на сервере ФОРМА, то это тоже связанно с другими функциями моей горе-программы. И еще одно, я полностью согласна, что надо осуществлять передачу, используя таймер, но это не решает проблему. А на мысль с условием if form3.showing then ... натолкнулась на одном из форумов. По моему хорошее решение и не надо никаких таймеров - результат тот же. P.S. проверенно.

Почитав документацию, выяснила, что РАДМИН написан для работы с TCP, но он же использует специальный драйвер - и это его фишка.

Испробовала также код, приведенный код в вашем же форуме с передачей скриншота, и опять все те же, описанные выше ошибки.

Или взять скажем уже готовые программы для удаленного администрирования - у многих них при разворачивании на весь экран происходят похожие проблемы. И не только при разворачивании.

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

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

> разбиваем поток на несколько частей

Этого делать не нужно, да и не поможет!
Основная задержка при сжатии из БМП в ДЖИПЕГ.
если у тебя 100Мбит то 100000000/8=1250000 Кбайт/с достаточно для того чтобы посылать приблизительно 5-8 кадров 1024:768 в секунду.

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

И почему оно будет быстрее?

> если у тебя 100Мбит то 100000000/8=1250000 Кбайт/с достаточно
> для того чтобы посылать приблизительно 5-8 кадров 1024:768
> в секунду.

Положим всю сеть... :)

В джипег конечно :)
РАдмин использует алгоритм анализа изменения изображения на экране, и посылает только то, что изменилось. Я дал ссылку выше, там сайт с протоколами и описаниями видео форматов МПЕГ. принципы работы. почитай может поможет.
Ну и наверное не обойдется без какого-нибудь драйвера прослойки между основными видео драйверами.

> Положим всю сеть... :)


Конечно, но если делать скриншотами, то только так :)

1250000 байт/с :)

> Конечно, но если делать скриншотами, то только так :)

А так не надо делать, а она вот уперлась :) выбрали и все тут...

> Этого делать не нужно, да и не поможет!Основная задержка
> при сжатии из БМП в ДЖИПЕГ. если у тебя 100Мбит то 100000000/8=1250000
> Кбайт/с достаточно для того чтобы посылать приблизительно
> 5-8 кадров 1024:768 в секунду.


у вас на форуме нашла ветвь intel jpeg libruary и сокеты, попробывала сжимать с помощью этой библиотеки вродибы получилось - все сжалось, но есть проблема: эта библиотека вродибы не позволяет сохрянять данные в поток, поэтому приходиться сохранять сначала в виде файла, потом в переменную jpg : Tjpegimage загружаем изображение из файла, а только потом сохраняем все в поток. Но похоже, что обчинка выделки не стоит.
Или я опять что не так делаю.

Буду разбираться с вашими советами и ссылками и копать в сторону принципаов радмина.

Senk you very much...

> Или я опять что не так делаю


Именно.

Передавать следует не весь шот, а только его изменения отн-но предыдущего шота.

Огромную помощь в этом оказывает display mirror driver.

> Огромную помощь в этом оказывает display mirror driver.


а теперь подробнее, пожалуйста.

что это такое, где его взять и главное как этим пользоваться?

> olchick ©


> Сначала моя программа была ориентирована на Tcp, но в связи
> с несколькими возникшимся проблемами, а именно: низкая скорость
> передачи, мерцание при смене картинки в image

Я могу передать не то что по TCP, а даже по HTTP кадров 200 в секунду. Так что в UDP смысла нет.

> olchick ©   (03.06.09 17:05) [29]


> у вас на форуме нашла ветвь intel jpeg libruary и сокеты,
>  попробывала сжимать с помощью этой библиотеки вродибы получилось
> - все сжалось, но есть проблема: эта библиотека вродибы
> не позволяет сохрянять данные в поток

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

> а даже по HTTP кадров 200 в секунду

О_о интересно посмотреть на скрипт)

> brother ©


> О_о интересно посмотреть на скрипт)

Да это у меня не скрипт, а целая большая программа, что-то вроде прокси-сервера или ретранслятора для IP камер. Принимает один поток - отдает множеству клиентов. Для гигабитной сети и 1000 кадров в сек (JPEG) реально передать.

> > а даже по HTTP кадров 200 в секунду

? это 200 запросов или типа кэша и аджакса с буфером в 200 кадров?

> brother ©   (16.06.09 04:11) [37]


> это 200 запросов

Нет конечно. Один поток - один запрос. Каждый кадр не запрашивается. Поток бесконечен и выдается клиенту пока тот желает его принимать. Кадры разделены разделителями.
Content-type: multipart/x-mixed-replace

> Поток бесконечен и выдается клиенту пока тот желает его
> принимать. Кадры разделены разделителями.
> Content-type: multipart/x-mixed-replace

а, понял