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

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

Здравствуйте, Mamut, Вы писали:
M>В ведге так и происходит. Правда, автор и Шеридан почему-то обижаются, когда им указывают на то, что браузер работает точно так же
Ну они видимо обижаются на сравнение с html-gui. Автор ведги, похоже, недолюбливает html. Все-таки в ведге гуй более нативный — типичные окошки-кнопочки.

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

KV> Ну может слегка тормозил, а я этого из-за 3G не заметил, не знаю. Я до сих пор в этот феномен въехать не могу).

Ничего хитрого в этом нет. Просто при создании сетевой части использовался ряд простых и очевидных принципов.

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

AVK>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>> Ну может слегка тормозил, а я этого из-за 3G не заметил, не знаю. Я до сих пор в этот феномен въехать не могу).

AVK>Ничего хитрого в этом нет. Просто при создании сетевой части использовался ряд простых и очевидных принципов.

Перечислил бы их что-ли. А то не так уж и мало очевидных принципов на ум приходит, интересно, какие именно теперь можно смело заносить в best-practices, проверенные в боевой обстановке

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

KV>Перечислил бы их что-ли.

О, когда я говорил про простые и очевидные, я ни капельки не преувеличивал.
1) По возможности осуществлять как можно больше операций за один раундтрип. Чем меньше раундтрипов, тем лучше.
2) Как можно меньше блокировать основной функционал во время общения по сети.
3) Постоянно помнить о том, что канал, который то потухнет, то погаснет — это норма жизни, и соответствующим образом обрабатывать исключения при работе с сетью.

KV> А то не так уж и мало очевидных принципов на ум приходит

Видимо ты думаешь, что это некое специфичное ноу хау. На самом деле все намного проще.

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

А может все проще, и веб-сервис Януса просто не ддосили?

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

H>А может все проще, и веб-сервис Януса просто не ддосили?

Веб-сервис януса это неотделимая от сайта его часть, а не нечто отдельное.

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

AVK> H>А может все проще, и веб-сервис Януса просто не ддосили?

AVK> Веб-сервис януса это неотделимая от сайта его часть, а не нечто отдельное.

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

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

H> Если предположить, что обработчики енд-поинтов у сайта и Януса будут находится в разных процессах

А если предположить, что Луна состоит из сыра ... Сервис януса находится в том же процессе и даже в том же веб-приложении, что и остальной функционал сайта.

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

AVK> H> Если предположить, что обработчики енд-поинтов у сайта и Януса будут находится в разных процессах

AVK> А если предположить, что Луна состоит из сыра ... Сервис януса находится в том же процессе и даже в том же веб-приложении, что и остальной функционал сайта.

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

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

KV>> А то не так уж и мало очевидных принципов на ум приходит
AVK>Видимо ты думаешь, что это некое специфичное ноу хау. На самом деле все намного проще.

Тут ведь какое дело... Когда я упоминаю тут про какую-нибудь атаку на веб-приложение, отличную от DDOS, XSS или SQL-инъекций многие тоже считают, что это какое-там ноу-хау, все сложно и т.п. А когда объясняю подробнее, то по полученным оценкам становится понятно, что они просто не представляли себе, что ту или иную фичу http/js/html и пр. можно применять таким образом. Хотя все составляющие атаки были им известны и без меня.

Вот в данном случае — все то же самое, только наоборот

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

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

AVK>> H> Если предположить, что обработчики енд-поинтов у сайта и Януса будут находится в разных процессах
AVK>> А если предположить, что Луна состоит из сыра ... Сервис януса находится в том же процессе и даже в том же веб-приложении, что и остальной функционал сайта.

H>Ну мне только предполагать и остается Я испытывал IIS со своим ISAPI, так при шквале запросов мой ISAPI прекрасно жил в нескольких процессах IIS. К тому же, запросы к Янусу легко отделяются от запросов непосредственно к сайту, и там где у "обработчика сайта" будет очередь, у "обработчика Януса" будет свободно. Впрочем, наверное только ддос Януса может показать реальную картину...

Хинт: бывает еще http-flood, нацеленный не столько на веб-сервер, сколько на сервер БД

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

k> Хинт: бывает еще http-flood, нацеленный не столько на веб-сервер, сколько на сервер БД

К данному случаю вряд ли отношение имеет А если вообще, то атаковать можно и конкретные особенности платформы. VladD2, в статье о сериализации в .NET писал:

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

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