Микрософт, что же ты делаешь, прекрати

[metaclass]

Два дня долблюсь в WCF, чтобы понять, как сунуть в RESTful сервис всякие хитрые способы аутентификации - примерно в стиле "проверяем откуда пришел запрос, проверяем хидеры-куки-итд, и либо аутентифицируем по ним, либо инициируем digest или ntlm аутентификацию".
Вывод, который я сделал пару лет назад насчет WCF, не изменился - over-engineered индусятина, с безумной архитектурой и безумным кодом (вплоть до полной бессмыслицы).
При этом, внезапно, микрософт сделал deprecated WCF REST starter kit, в котором был перехват запросов на уровне канала, до превращения их в Message. Сейчас из подходящего остались IDispatchMessageInspector, но там толком нельзя сделать что-то вроде "проверить запрос и не пустить сообщение дальше, а вернуть 401".
И микрософт выкатила еще одно творчество на эту тему - ASP.NET Web API: http://msdn.microsoft.com/en-us/library/hh833994%28v=vs.108%29.aspx

Еще в процессе посмотрел два фреймворка для веб-сервисов и веб-приложений - https://github.com/ServiceStack/ServiceStack и https://github.com/NancyFx/Nancy . У обоих есть вариации на тему "хостинг в своем приложении", "хостинг поверх WCF", "Хостинг в IIS".
Причем, WCF хостинг на самом деле является многослойной пиздецомой поверх того же базового HttpListener который используется в "своем хостинге". В WCF поверх него накручена асинхроннная обработка запросов, фоновые потоки с чем-то вроде IO Completion Ports. Рефлектором это дело посмотрел - понять, какой из вариантов принципиально лучше и какой в этом вообще смысл, сходу не получилось.

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

Comments

[stdray.livejournal.com]

А можно краткий экскурс, чем так сильно хорош IIS? То есть в сравнении с тем же HttpListener откуда возьмется большая разница в производительности?

[enternet.livejournal.com]

Эээ... Не знаю что и сказать. Нуу, скажем так, технически-то они оба поверх http.sys работают. Поэтому и ежу понятно, что при грамотной работе с HttpListener производительность будет идентична. Просто мне лично не нравится изобретение велосипедов. Работа с IIS проста и не очень понятно зачем тратить время на самостоятельное изобретение всей той обвязки которая, собственно, и является современным веб-сервером. Например. Несколько лет назад я как-то с утра решил написать собственный comet(?)-сервер, не помню зачем. Ну и начал приблизительно с того же, что и метакласс: потыкал палкой уже написанное, почитал про чужие наработки, сделал пару демок из чужого кода. Ну и пришел ровно к тому же выводу: это же песец какой-то. А потом сделал себе демо на IHttpHandler/IHttpAsyncHandler, потюнил, смотрю 40Krps на моей дохлой машинке как с куста и коннектов тыщи длинных. И так всё элементарно и кода мало, что пожалел, что потратил время на изучение чужих велосипедов.

IIS сервер достаточно простой, чего его боятся - непонятно. Не хуже других.

[stdray.livejournal.com]

Я, прочитав сообщение, подумал, что остальные варианты сильно проигрывают в производительности IHttpHandler. У меня нет претензий к IIS, на работе его и использую. Просто мне непонятно, почему для дотнетов по сути есть один единственный веб-сервер существует.
А иногда желательно сделать веб-приложение на дотнетах с минимумом инфраструктурных зависимостей. А тут кроме этих self-host нанси и сервисстэка ничего и нет. А потом я смотрел какие-то такие бенчмарки , где непонятно: или тесты кривые, или фреймворки настолько медленные или моно настолько убогое, или комбинации перечисленного. Ну и решил уточнить на всякий случай про фатальные недостатки, поскольку я как раз собираюсь велосипедов пописать.

>А потом сделал себе демо на IHttpHandler/IHttpAsyncHandler, потюнил, смотрю 40Krps на моей дохлой машинке как с куста и коннектов тыщи длинных.
Это можно где-то посмотреть самообразования ради?

[enternet.livejournal.com]

Удивительно, но нашел кусок старого кода по комету. Помидорами не кидать! Код академический ) https://gist.github.com/enternet/6684188

Не помню каким тестом там было 40Krps. Это же комет, ему кол-во соединений важно, а не rps. Кол-во соединений там судя по комментариям было в диапазоне 10-20K. Но центральная суть в коде, что для соединений, что для rps одна и та же - аккуратная работа с IHttpAsyncHandler и IAsyncResult. И именно для этого дела кода нужно очень мало. Код по очередям/потокам/синхронизации/json можешь не смотреть: это просто старый трешак - всё уже готовое есть в последнем C# и dotNet.

[enternet.livejournal.com]

Метакласс, открой личико комментарий. А то он в подозрительные попал.

[metaclass.livejournal.com]

Открыл.