Приветствую, Mamut, вы писали:

M> M>> 100 тыс. клиентов. 20 байт на каждое телодвижение мышки.
M> S>Неверно. Впрочем можно конечно каждое телоджвижение мыша на сервер отправлять, но зачем?
M> S>По сети ходят только сигналы от контролов, интерфейс и данные. Тоесть движение мыша не отправляется. Отправляется к примеру клик по кнопке (десятки байт), да и то, если сигнал прописан.
M> S>Неверный вывод основанный на неверном предположении.

M> Одно (два?) слово: drag and drop
Драгидроп — это по твоему "каждое телодвижение мыша"? о0

Здравствуйте, Тот кто сидит в пруду, Вы писали:
ТКС>Никогда не видел на форумах посты по три раза? Всего лишь обрыв связи. А казалось бы — hhtp к нему устойчив...
Видел тут пару раз. Также видел, что на некоторых форумах проблема с этим решена.

MC>>С ajax/flex/silverlight — момент коннекта к серверу явно прописан — ошибку коннекта можно обработать в коде.
ТКС>Вообще при некоторых моделях построения приложения эти вопросы может и библиотека порешать. Тупо спросить пользователя например — уже забъём или попробуем еще разок пересоединиться.
Ну или так.

ТКС>Да вообще в толстых клиентах проблема с дропаньем контекста пользователя на стороне сервера вроде как не особо сложно решается. Явно отсоединился — бросаем контекст сразу, отвалился с ошибкой/просто не дает о себе знать — ждем какое-то время (время можно выбирать адаптивно, в зависимости от нагрузки). И ничего принципиально лучшего по-моему и не придумаешь...
Все эти рассуждения замечательны (кстати, везде прослеживается возможность программиста писать какую-то логику, связанную с ошибками коннекта).
Один вопрос остается — а в ведге/кальпе как сделано-то? Что делает система по дефолту при проблемах с коннектом? Как программист может влиять на поведение системы в этом случае?

Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, Тот кто сидит в пруду, Вы писали:
ТКС>>Никогда не видел на форумах посты по три раза? Всего лишь обрыв связи. А казалось бы — hhtp к нему устойчив...
MC>Видел тут пару раз. Также видел, что на некоторых форумах проблема с этим решена.

Ну просто в случае http об этом специально думать надо, а не оно само собой силами протокола делается.

MC>>>С ajax/flex/silverlight — момент коннекта к серверу явно прописан — ошибку коннекта можно обработать в коде.
ТКС>>Вообще при некоторых моделях построения приложения эти вопросы может и библиотека порешать. Тупо спросить пользователя например — уже забъём или попробуем еще разок пересоединиться.
MC>Ну или так.

ТКС>>Да вообще в толстых клиентах проблема с дропаньем контекста пользователя на стороне сервера вроде как не особо сложно решается. Явно отсоединился — бросаем контекст сразу, отвалился с ошибкой/просто не дает о себе знать — ждем какое-то время (время можно выбирать адаптивно, в зависимости от нагрузки). И ничего принципиально лучшего по-моему и не придумаешь...
MC>Все эти рассуждения замечательны (кстати, везде прослеживается возможность программиста писать какую-то логику, связанную с ошибками коннекта).

Вообще-то это можно целиком на библиотечный код переложить — rpd клиент же в конце-концов как-то с реконнектами сам справляется. Ведга, как понимаю, с точки зрения клиентской функциональности (ни строчки кода не пишется прикладным программистом, просто визуализируется передаваемое с сервера состояние) к нему ближе всего.

MC>Один вопрос остается — а в ведге/кальпе как сделано-то? Что делает система по дефолту при проблемах с коннектом? Как программист может влиять на поведение системы в этом случае?

Да без понятия. Главное, все это разработчик библиотеки может прикрутить в лююой момент, никого не напрягая. Хотя он может конечно и забить, и тогда как с DCOM получится...

M>> M>> 100 тыс. клиентов. 20 байт на каждое телодвижение мышки.
M>> S>Неверно. Впрочем можно конечно каждое телоджвижение мыша на сервер отправлять, но зачем?
M>> S>По сети ходят только сигналы от контролов, интерфейс и данные. Тоесть движение мыша не отправляется. Отправляется к примеру клик по кнопке (десятки байт), да и то, если сигнал прописан.
M>> S>Неверный вывод основанный на неверном предположении.

M>> Одно (два?) слово: drag and drop
S>Драгидроп — это по твоему "каждое телодвижение мыша"? о0

hover и rollover-эффекты, драгндроп — это все движение мыши. ты или "утяжеляешь" клиент, позвояля ему самостоятельно решать, что делать в таком случае (в частности, не бегать на сервер за изменением состояния) или постоянно шлешь на сервер никому ненужную информацию. как там было с тим в ведге когда-то, не помню.

Здравствуйте, Тот кто сидит в пруду, Вы писали:
ТКС>Ну просто в случае http об этом специально думать надо, а не оно само собой силами протокола делается.
Ну да. Где-то надо думать, где-то не надо.

ТКС>Вообще-то это можно целиком на библиотечный код переложить — rpd клиент же в конце-концов как-то с реконнектами сам справляется. Ведга, как понимаю, с точки зрения клиентской функциональности (ни строчки кода не пишется прикладным программистом, просто визуализируется передаваемое с сервера состояние) к нему ближе всего.
А вот мне наоборот показалось, что автор противопоставлял ведгу rdp и ведга нацелена скорее на RIA — просто с автоматической организацией взаимодействия клиента и сервера. Впрочем, если ведга и правда нацелена быть аналогом rdp — тогда согласен.

Здравствуйте, Mr.Cat, Вы писали:

ТКС>>Вообще-то это можно целиком на библиотечный код переложить — rpd клиент же в конце-концов как-то с реконнектами сам справляется. Ведга, как понимаю, с точки зрения клиентской функциональности (ни строчки кода не пишется прикладным программистом, просто визуализируется передаваемое с сервера состояние) к нему ближе всего.
MC>А вот мне наоборот показалось, что автор противопоставлял ведгу rdp и ведга нацелена скорее на RIA — просто с автоматической организацией взаимодействия клиента и сервера. Впрочем, если ведга и правда нацелена быть аналогом rdp — тогда согласен.

Ну я просто отличий от rdp конкретно в этом аспекте не вижу. А от RIA — отличия очевидны, у RIA без клиентского не-библиотечного кода не обходится. А что про это думает автор, и вовсе не важно. Он и ошибаться может, и врать у него мотивов больше чем у всех остальных.

Приветствую, Mr.Cat, вы писали:

MC>Впрочем, если ведга и правда нацелена быть аналогом rdp — тогда согласен.
Да совершенно не аналог. Рдп,внс,радмин — это передача графики, координат мыша и нажатых кнопок по сети. Ведга оперирует описанием интерфейса, сигналами и данными.

Приветствую, Mamut, вы писали:

M> M>> M>> 100 тыс. клиентов. 20 байт на каждое телодвижение мышки.

M> M>> S>Неверно. Впрочем можно конечно каждое телоджвижение мыша на сервер отправлять, но зачем?
M> M>> S>По сети ходят только сигналы от контролов, интерфейс и данные. Тоесть движение мыша не отправляется. Отправляется к примеру клик по кнопке (десятки байт), да и то, если сигнал прописан.
M> M>> S>Неверный вывод основанный на неверном предположении.

M> M>> Одно (два?) слово: drag and drop

M> S>Драгидроп — это по твоему "каждое телодвижение мыша"? о0

M> hover и rollover-эффекты,
Зависят от темы, и обрабатываются клиентом без участия сервера. Если конечно ты не захотел специальный эффект и специально не описал его. В любом случае это всего 2 события — onenter onleave

M> драгндроп — это все движение мыши.
Емнип тут события такие: ondragstart, onenter в элемент чтобы проверить может ли туда объект упасть и собственно событие dragstop или как оно там — которое "кидает" то что тащишь в объект.
Никаких передач каждой координаты мыша при ее движении нет, событий единицы, хоть затаскайся.

M> ты или "утяжеляешь" клиент, позвояля ему самостоятельно решать, что делать в таком случае (в частности, не бегать на сервер за изменением состояния) или постоянно шлешь на сервер никому ненужную информацию. как там было с тим в ведге когда-то, не помню.
Достаточно отсылать описанные выше сигналы, а их не сотни, как ты пытаешься тут показать.
Я точно не помню как точно называются эти сигналы, но ты понял что я имею ввиду.

Здравствуйте, Тот кто сидит в пруду, Вы писали:
ТКС>Ну я просто отличий от rdp конкретно в этом аспекте не вижу. А от RIA — отличия очевидны, у RIA без клиентского не-библиотечного кода не обходится.
Да, возможно я, когда слышу про ведгу, думаю о чем-то своем. У меня почему-то сразу возникают ассоциации, как какой-то код помечается как вызываемый на сервере, а какой-то — как вызываемый на клиенте — и далее в ту степь.
Видимо, у ведге надо подходить так, что клиент от сервера получает только структуру контролов, а с сервером общается примерно так: "у меня тут нажали — обнови мне структуру контролов". Тогда это получается некий аналог html-ного гуя. Ну или можно попробовать что-то такое на ajax-е навернуть — если все-все события пойдут через один обработчик — который будет коннектиться к серверу, слать инфу и обновлять дерево.

Здравствуйте, Sheridan, Вы писали:

M>> Одно (два?) слово: drag and drop
S>Драгидроп — это по твоему "каждое телодвижение мыша"? о0

Важно то, что злоумышленник вполне легко может устроить сразу с нескольких компов с запущенной тысячью-другой клиентов ситуацию "не секунды без драг&дропа".

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, Anton Batenev, вы писали:

AB>> M> 100 тыс. клиентов.
AB>> Не получится на одном IP с постоянными соединениями.
S>Ну у нас процессор в памяти

Автор: Sheridan
Дата: 27.11.09

, нам все можно.

А дело не в процессоре, а в том, к чему я вообще это начал спрашивать. После исчерпания тех или иных ресурсов, сервер ведги будет давать отлуп всем вновь подключающимся клиентам до тех пор, пока кто-то из уже работающих не отвалится. При использовании HTTP картина получается "несколько" иная. Не в пользу ведги.

Иными словами, ведга совершенно импотентна перед DDOS-атаками

Приветствую, kochetkov.vladimir, вы писали:

k> Важно то, что злоумышленник вполне легко может устроить сразу с нескольких компов с запущенной тысячью-другой клиентов ситуацию "не секунды без драг&дропа".

Как я уже сказал ниже, драгидроп в смысле обмена данными по сети мало чем отличается от простого нажатимя на кнопку.
Но повторю еще раз: каждую смену координат мыша никто не передает. Ходят события onenter on leave.

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

Здравствуйте, Sheridan, Вы писали:

S>Но если так судить, то злоумышленник может запустить десятки тысяч соединений вообще. На любой сервис, не только на ведгу.

Разумеется может. Это вообще-то и называется DDOS-атакой (одной из ее разновидностей, если быть точным). Вот, недавно и этот сайт DDOSили

Автор: AndrewVK
Дата: 13.11.09

. Обрати внимание, что пишет Павел (пишет во время атаки, заметь): "Сегодня тормозит безбожно, до минуты", а не (по почте) "вообще не могу зайти на сайт, service unavailable, и все тут".

Что характерно, во время атаки зайти на сервер по RDP было вообще нереально. По SSH я зашел с n-ой попытки, минуте на 15-ой. А сайт исправно отдавал всем контент с минутной задержкой (а янус, зараза, вообще как работал до атаки, так и продолжил работать во время нее. Ну может слегка тормозил, а я этого из-за 3G не заметил, не знаю. Я до сих пор в этот феномен въехать не могу).

Внимание вопрос: что объединяет сайт и янус и отличает их от remote desktop и ssh?

Приветствую, kochetkov.vladimir, вы писали:

k> Внимание вопрос: что объединяет сайт и янус и отличает их от remote desktop и ssh?
Этот вопрос.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, kochetkov.vladimir, вы писали:

k>> Внимание вопрос: что объединяет сайт и янус и отличает их от remote desktop и ssh?
S>Этот вопрос.

Ответ неправильный. А ведь мог хотя бы помощь зала или звонок другу сначала взять

Сайт и янус используют HTTP, сессия в котором может выглядеть как некоторое число последовательностей "подключились-запрос[ы]-ответ[ы]-отключились-поработали с контентом". SSH и RDP же хоть и позволяют восстановливать сессию, но не дают возможности делать что-то в отсоединенном режиме (см. выделенное). Поэтому под DOS-атаками (или просто под сильной нагрузкой) HTTP их рвет как тот тузик.

Ок, снизим сложность вопросов: к какой из этих двух групп протоколов ближе протокол ведги?

Приветствую, kochetkov.vladimir, вы писали:

k> Ок, снизим сложность вопросов: к какой из этих двух групп протоколов ближе протокол ведги?

Давай сразу к итогу?
Ты хочешь сказать что злоумышленник просто насоздает толпу коннектов к серванту, чем создаст невозможность подключения других?
Увы, так работает (коннект-полезнаядлительнаяработа-дисконнект) подавляющее большинство сервисов. Ведга подвержена подобным атакам равно как и множество других сервисов. И ты как, хочешь сказать что не существует защиты от подобного типа атак? Первое что приходит в голову — один коннект с 1го ip, что конечно взломщиком легко обходится. Ну в принципе и так далее.

ТКС>>Ну я просто отличий от rdp конкретно в этом аспекте не вижу. А от RIA — отличия очевидны, у RIA без клиентского не-библиотечного кода не обходится.
MC>Да, возможно я, когда слышу про ведгу, думаю о чем-то своем. У меня почему-то сразу возникают ассоциации, как какой-то код помечается как вызываемый на сервере, а какой-то — как вызываемый на клиенте — и далее в ту степь.
MC>Видимо, у ведге надо подходить так, что клиент от сервера получает только структуру контролов, а с сервером общается примерно так: "у меня тут нажали — обнови мне структуру контролов". Тогда это получается некий аналог html-ного гуя.

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

M>> ты или "утяжеляешь" клиент, позвояля ему самостоятельно решать, что делать в таком случае (в частности, не бегать на сервер за изменением состояния) или постоянно шлешь на сервер никому ненужную информацию. как там было с тим в ведге когда-то, не помню.
S>Достаточно отсылать описанные выше сигналы, а их не сотни, как ты пытаешься тут показать.
S>Я точно не помню как точно называются эти сигналы, но ты понял что я имею ввиду.

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


ЗЫ. То есть клиент так или иначе утяжелен каким-то доп. функционалом В данном случае — решать, когда генерировать сигналы.

Приветствую, Mamut, вы писали:

M> ЗЫ. То есть клиент так или иначе утяжелен каким-то доп. функционалом В данном случае — решать, когда генерировать сигналы.
Клиент тут не при чем. Все делает qt плюс привязка слотов к сигналам.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, kochetkov.vladimir, вы писали:

k>> Ок, снизим сложность вопросов: к какой из этих двух групп протоколов ближе протокол ведги?

S>Давай сразу к итогу?

Давай. Ведга противопоставляется автором в т.ч. и веб-приложениям. Веб-приложения, будучи построенными на протоколе HTTP, в силу его stateless и асинхронности, гораздо менее подвержены подобным угрозам. "Гораздо менее" == "несколько порядков". Т.о., как минимум, в этом отношении, у ведги особых преимуществ перед веб-приложениями нет.