Извиняюсь, но нормальное состояние программы во время её разработки — это когда что-то не работает. Иначе зачем трудиться над ней? всё ведь уже работает само собой…
Искать и исправлять ошибки — это один из важнейших моментов работы программиста.
Грамотный и опытный программист ценится не только за умение делать меньше ошибок (и следовательно тратить меньше времени на выдачу необходимого результата), но и за его навыки в архитектуре, умении предвидеть возможные улучшения в дальнейшем и минимизировать затраты на их реализацию благодаря правильному дизайну и выбору технических решений.
То есть ДОработка — это часть РАЗработки.
Многие, кто называют себя программистами считают, что «после нас — хоть потоп», написал код и забыл. Мы ведь не о них тут говорим, правда? :)
Философский вопрос ты себе задал.
Много толковых советов от людей, которые на него для себя уже ответили.
Мне кажется что нужно опираться на реальность.
Если пойдёшь в науку, то по-настоящему наукой в сегодняшних условиях в России (если ты уезжаешь в Штаты, то всё немного по-другому конечно) заниматься очень трудно, наслышан. Получается, что при поставленном вопросе (или-или, третьего почему-то не дано) нужно идти в программисты. К сожалению многие так делают.
Тут кто-то говорил уже, что действительно толковых программистов сейчас мало — порог «становления программистом» настолько снизился, что им можно уже стать чуть ли не за вечер.
Но чтобы стать хорошим инженером нужно любить свою профессию, это должно для тебя стать целым искусством. Да в общем так во всём. Ответь для себя — захотел бы ты копаться всю ночь до утра, дописывая и тестируя какой-нибудь модуль ДЛЯ СЕБЯ? т.е. зная, что тебе за это никто ничего не заплатит? Если нет, то может быть поискать другие варианты? Чёрт побери, почему свет клином на программировании сошёлся? :)
И ещё, вот эта фраза — «Ужасно боюсь ошибиться в выборе. Не хочу потом жалеть всю жизнь, что выбрал неверный путь.» ключевая.
Никогда не жалей о выборе, всегда иди вперёд, пробуй и не бойся ошибаться! Жизнь одна, и она должна быть яркой, насыщенной. А если ты будешь думать только о зарплате, делая только то, что тебе скажут — она пролетит незаметно.
Нужно всегда решать трудные задачи, только тогда можно чего-то добиться в жизни.
Да, кажется мы шагнули в новую ЭПОХУ. Дата войдёт в историю.
Согласен, что назревала эта идея уже давно и для некоторых уже начала «тускнеть», но заложенные принципы думаю будут жить ещё долго…
Самое смешное, что цикл тех прогресса прошёл полный круг — мы опять вернулись во времена больших мэйнфреймов (прости меня господи, не к ночи будет сказано) и терминалов :)
PS
Чёрт побери, сам из-за этого сегодня уснуть не могу, слава богу что не в пятницу вечером :)
Ну на статью у меня времени нет, а если на пальцах то всё довольно примитивно.
В soap-конверте есть заголовок и тело, в котором собственно передаются параметры методов и результаты. Как всегда нужно обеспечить цифровую подпись конверта и иметь возможность БЫСТРО идентифицировать клиента.
Ну подпись генерируется по криптованному уже конечному контенту и вставляется в заголовок завёрнутая в специальный xml тэг.
Остаётся поместить туда же сертификат клиента чтобы сервер мог проанализировать его в первую очередь.
Ну вот и получается, что способов шифрования существует много — RSA, Kerberos итд, для каждого способа ключи и способ дешифрации немного разные. Вот стандарт WS-Security и описывает какие тэги нужно использовать в заголовке и с какими атрибутами.
С сигнатурой та же история — способов подписи несколько, нужно указать каким алгоритмом проверять.
Поначалу мы гоняли всё внутри SSL-туннеля, но он сильно просаживал CPU при наших объёмах. Да и не только у нас, поэтому и подключились к стандартизации. Дело в том, что по заголовку можно разбрасывать конверты по разным бэкендам, различая их по ключам например. Декриптовать само тело конверта на фронтенде не требуется.
Замечу, что переговоры по стандарту проходили медленно, всем хотелось сделать что-то краткое и ёмкое. Быстро стало ясно, что не получится, хотя работу над стандартизацией до конца мы довели. Потом там ещё много «WS-» стандартов было принято, но я уже не очень за этим следил.
Дело было в 2003 году, у всех тогда был пылкий интерес к вебсервисам и интернет пестрил статьями про «поворотное событие в распределённом software». На деле оказалось, что когда всё красиво смоделируешь в wsdl, то сервера умирают под нагрузкой — столько xml нужно парсить да ещё и проверять на соответствие xsd! Короче осадок остался один — это та же корба, только переписанная под xml со всеми вытекающими последствиями.
Для веба пользуйтесь REST, люди докторские не просто так получали за это (Рой Филдинг кажется). Для некоторых не очень сложных случаев вполне можно использовать и вебсервисы, хотя новое что-то я бы под них не стал сейчас создавать, их время прошло.
Несколько неточностей есть. Нужно понимать разницу между форматом данных и протоколом.
XML-RPC: Пожалуй самый старый подход — данные в виде XML передаются посредством RPC (remote procedure call). Это вообще появилось с появлением XML, просто его стали использовать как формат для передаваемых параметров удалённых функций. Заметьте, что HTTP тут вообще ни при чём, это просто неточная интерпретация терминологии. И кстати, RPC как правило требует permanent connection между клиентом и сервером.
REST: Тут действительно оптимально используется протокол HTTP, со всеми глаголами. Короче, нет слов — всё очень красиво и эффективно.
SOAP: Это всего лишь стандартизированный формат передаваемых данных. Тот же XML, но с предварительно описанными в XSD типами (XSD можно вставить прямо в WSDL), сообщениями, binding-ом сообщений на методы, структурированием методов в группы и описанием собственно WebService-а. SOAP всегда ходит по какому-нибудь протоколу. У вас подразумевается HTTP, но мы однажды его пускали даже поверх Tibco, надо было :) В целом SOAP описывает то, что из себя представляет SOAP envelop и вообще, WebServices — это XML-пародия на ставшую в своё время черезчур сложной Corba. Вспомните, в корбе у нас IIOP — в вебсервисах SOAP, в корбе IDL — в вебсервисах WSDL…
В своё время я участвовал в стандартизации WS-Security в OASIS, там даже никаких токенов секурити тогда ещё не было.
У меня так: --- begin ---
options IPFIREWALL
# We comment this because it works OK and no debugging is needed
#options IPFIREWALL_VERBOSE
#options IPFIREWALL_VERBOSE_LIMIT=100
options IPDIVERT
options IPFIREWALL_FORWARD
# FYI: for kernel nat:
options IPFIREWALL_NAT #ipfw kernel nat support
options LIBALIAS
---- end ----
Кажется в этом месте я ничего в последнее время не менял… Разумеется если ядерный nat не нужен — можно выкосить последние две строчки.
DUMMYNET и IPSTEALTH не пользуюсь. Подозреваю что IPDIVERT мне не нужен (остался со времён не-ядерного ната), посмотрю попозже и пожалуй уберу.
Почитать можно как всегда man ipfw, секцию NAT.
Handbook немного устарел по этой теме, но вот тут можете почитать как это делается.
Спасибо, многим в наши дни стоит познакомиться с по-настоящему грамотным инструментарием, который отточен десятилетиями.
Сам vim пользуюсь только для правки конфигов, предпочитаю для разработки использовать emacs (не знаю, лучше он или хуже чем vim). Тоже поначалу адаптировался некоторое время, но зато потом он просто становится гармоничным продолжением рук, можно кодить хоть на чём быстро и не отвлекаясь на ненужные рюшечки с свистульки.
Если вкратце, то в 8-ке полностью переработана подсистема usb, множество улучшений в сетевой части (особенно wifi стек), список длинный, пересказывать /usr/src/UPDATING можно долго.
Для тех, кто сомневается переходить ли с предыдущей версии на 8-ку могу посоветовать посмотреть стоп-лист багов на /releng страничке. Если то, что там написано вами не используется, то вполне можно попробовать «пересоздать мир» :)
В общем, если всё делать неторопясь, вдумчиво, отдавая себе отчёт что и зачем вы делаете (BSD style кстати), то за викенд вполне можно подняться до RELENG_8.
Из того, что запомнилось с этого апгрейда мне лично:
— wifi интерфейсы теперь всегда оборачиваются в wlan (даже если они learned by if_bridge!) => нужно немного подправить /etc/rc.conf и ещё где там у вас жёстко указано имя интерфейса.
— usb устройства теперь имеют вид ugenX.Y => тоже может кое-где конфиги подправить нужно будет.
— есть несколько устаревших options в файле конфигурации ядра, но make вам это сам сообщит, не торопитесь в этом месте, почитайте UPDATING, посмотрите конфиги GENERIC и NOTES.
В целом всё взлетело без единого чиха, я как всегда остался доволен надёжностью и предсказуемостью системы.
Те, кто сомневается переходить ли на FreeBSD с другой системы — убеждать не буду, если вам интересно — пробуйте.
> модель выдержит любое количество операций в секунду, хоть триллион
Вы ошибаетесь и рассуждаете слишком поверхностно (только не обижайтесь пожалуйста)
> статья вызвала резонанс
Да, тема похоже для многих тут наболевшая :)
Правда споры в основном идут не о том — большинство отстаивают то, что лучше знают. Чёрт побери, столько шуму, а по сути — так несерьёзно…
Вот начиная с задач в десятки тысяч транзакций в секунду вся эта шелуха что в статье описана и осыпается, начинается реальный technical challenge.
У автора есть интерес к теме высокодоступных-высоконагруженных серверов, и это очень хорошо. Главное не останавливаться и продолжать разбираться/набираться опыта.
С практической точки зрения представленный хлам никуда не годится. Я имею ввиду что каждый программный модуль в отдельности конечно вещь стоящая, но вот всё вместе оставляет ощущение… хмм… некоторого бардака.
По идее нужно плясать от конкретной задачи, представить архитектуру, выяснить требования к каждому модулю, а уж затем рассуждать что они будут из себя представлять. А у вас — подход микрософт, подход гугл… Да грамотный архитектор вообще об этом не думает, какие у кого подходы! Он аргументы в пользу того или иного решения проверяет, proof of concepts мастерит. А эти решения ему опыт его даёт.
Универсальную архитектуру при жёстких требованиях не сделать — то там косяк вылезет, то там модуль отвалится. Видеть надо всю систему глобально, не упуская конечную цель.
И ещё, реально работающая высоконагруженная система, решающая определённую задачу, она выверяется годами. Речь конечно не идёт о случае когда вы копируете чью-то исходную задачу — тогда конечно её решение кто-то за вас уже выверил.
Мне доводилось участвовать в разработке подобных комплексов. Чутьё приходит с годами серьёзного опыта, причём от задачи к задаче решения могут быть разные в силу специфики контекста.
Эх, тема настолько обширная, что тут можно рассказывать очень долго…
Желаю вам дело это не забрасывать, ведь именно там, где мы решаем трудные задачи, мы обогащаем свой опыт бесценными знаниями.
> одробно объяснять, в каких случаях ничего поделать нельзя, будет неправильно — не хочется создавать инструкцию для мошенников
«Иногда лучше молчать, чем говорить» (с)
В данном случае, мошенник уже понял, что ваш клиент при таком раскладе будет вынужден иметь дело с милицией, сами вы ему почему-то помочь не захотите. Извините, но многие проходящие мимо поймут вас именно так.
Вам конечно видней, но может быть вы сообщите мою идею своему начальству? Или у вас за такое наказывают? 8-/
Да, сурово тут закрутилась дискуссия!
В этой истории странным мне кажется поведение господ из Яндекса — пассивное, безразличное к имиджу своей компании. Вон уже слышатся голоса, что ВебМани лучше, а карточки и подавно…
Блин, дарю Яндексу идею — включитесь АКТИВНО в распутывание этой детективной истории! Покажите что вы технически компетентны, что вам небезразличны ваши клиенты! Цена вопроса — 10000 рублей, зато какая вашему бизнесу будет реклама!
Меня бы такая история включила сразу, а вы — «пишите заявление», «идите в милицию»… Вы осознаёте что такой подход принесёт мало пользы?
Пока что от этой истории выиграют ваши конкуренты, но я бы на вашем месте повернул всё в вашу пользу. И в пользу вашего клиента конечно…
PS Автор молодец, искренне желаю ему успешного разрешения этой проблемы и спасибо за тему, которая затрагивает тут многих людей.
Всё зависит от настройки прокси — отдаёт он заголовок X-Forwarder-For наружу или нет. Если в яндексе показывается реальный внешний айпи, то значит не выдаёт. ( конечно, если тэкинг смотрит этот заголовок )
FYI в squid за это отвечает «header_access X-Forwarded-For deny all»
Самое интересное, что с точки зрения маркетинга эффект который это произведёт на потребителя будет совсем противоположный :)
Обычный лямбда-пользователь, который поведётся на «0$» скорее всего быстренько перейдёт на по-настоящему бесплатный офисный пакет. А впечатление которое останется — «опять MS не довела до ума свой продукт»…
Для полноты картины можно было бы рассказать про цикл жизни сервиса, про системные утилиты для диагностики и управления ими. Также не заметил нигде упоминания про то, что сервис не обязательно должен быть exe. Там вообще много интересного внутри, людям кстати думаю было бы интересно увидеть краткое сравнение с юниксовыми демонами…
Хотя… зачем это всё нужно, открываем msdn и делаем, что тут нового?
Да, daapd у меня тоже там крутится, но я практически перестал его использовать — только когда хочется послушать что-нибудь этакое, да на наушниках где-нибудь в укромном уголке…
Тоже кстати интересная вещь, я так с помощью него тоже слушал одно время музыку прямо на работе :)
Вот уж где действительно клиент-серверная архитектура в действии :)
PS
Есть ещё QTSS (ака DarwinStreamingServer), пробовал с него сделать дома просмотр фильмов, но приходится всё конвертировать в mp4, в общем бросил эту затею.
Искать и исправлять ошибки — это один из важнейших моментов работы программиста.
Грамотный и опытный программист ценится не только за умение делать меньше ошибок (и следовательно тратить меньше времени на выдачу необходимого результата), но и за его навыки в архитектуре, умении предвидеть возможные улучшения в дальнейшем и минимизировать затраты на их реализацию благодаря правильному дизайну и выбору технических решений.
То есть ДОработка — это часть РАЗработки.
Многие, кто называют себя программистами считают, что «после нас — хоть потоп», написал код и забыл. Мы ведь не о них тут говорим, правда? :)
Много толковых советов от людей, которые на него для себя уже ответили.
Мне кажется что нужно опираться на реальность.
Если пойдёшь в науку, то по-настоящему наукой в сегодняшних условиях в России (если ты уезжаешь в Штаты, то всё немного по-другому конечно) заниматься очень трудно, наслышан. Получается, что при поставленном вопросе (или-или, третьего почему-то не дано) нужно идти в программисты. К сожалению многие так делают.
Тут кто-то говорил уже, что действительно толковых программистов сейчас мало — порог «становления программистом» настолько снизился, что им можно уже стать чуть ли не за вечер.
Но чтобы стать хорошим инженером нужно любить свою профессию, это должно для тебя стать целым искусством. Да в общем так во всём. Ответь для себя — захотел бы ты копаться всю ночь до утра, дописывая и тестируя какой-нибудь модуль ДЛЯ СЕБЯ? т.е. зная, что тебе за это никто ничего не заплатит? Если нет, то может быть поискать другие варианты? Чёрт побери, почему свет клином на программировании сошёлся? :)
И ещё, вот эта фраза — «Ужасно боюсь ошибиться в выборе. Не хочу потом жалеть всю жизнь, что выбрал неверный путь.» ключевая.
Никогда не жалей о выборе, всегда иди вперёд, пробуй и не бойся ошибаться! Жизнь одна, и она должна быть яркой, насыщенной. А если ты будешь думать только о зарплате, делая только то, что тебе скажут — она пролетит незаметно.
Нужно всегда решать трудные задачи, только тогда можно чего-то добиться в жизни.
Согласен, что назревала эта идея уже давно и для некоторых уже начала «тускнеть», но заложенные принципы думаю будут жить ещё долго…
Самое смешное, что цикл тех прогресса прошёл полный круг — мы опять вернулись во времена больших мэйнфреймов (прости меня господи, не к ночи будет сказано) и терминалов :)
PS
Чёрт побери, сам из-за этого сегодня уснуть не могу, слава богу что не в пятницу вечером :)
В soap-конверте есть заголовок и тело, в котором собственно передаются параметры методов и результаты. Как всегда нужно обеспечить цифровую подпись конверта и иметь возможность БЫСТРО идентифицировать клиента.
Ну подпись генерируется по криптованному уже конечному контенту и вставляется в заголовок завёрнутая в специальный xml тэг.
Остаётся поместить туда же сертификат клиента чтобы сервер мог проанализировать его в первую очередь.
Ну вот и получается, что способов шифрования существует много — RSA, Kerberos итд, для каждого способа ключи и способ дешифрации немного разные. Вот стандарт WS-Security и описывает какие тэги нужно использовать в заголовке и с какими атрибутами.
С сигнатурой та же история — способов подписи несколько, нужно указать каким алгоритмом проверять.
Поначалу мы гоняли всё внутри SSL-туннеля, но он сильно просаживал CPU при наших объёмах. Да и не только у нас, поэтому и подключились к стандартизации. Дело в том, что по заголовку можно разбрасывать конверты по разным бэкендам, различая их по ключам например. Декриптовать само тело конверта на фронтенде не требуется.
Замечу, что переговоры по стандарту проходили медленно, всем хотелось сделать что-то краткое и ёмкое. Быстро стало ясно, что не получится, хотя работу над стандартизацией до конца мы довели. Потом там ещё много «WS-» стандартов было принято, но я уже не очень за этим следил.
Дело было в 2003 году, у всех тогда был пылкий интерес к вебсервисам и интернет пестрил статьями про «поворотное событие в распределённом software». На деле оказалось, что когда всё красиво смоделируешь в wsdl, то сервера умирают под нагрузкой — столько xml нужно парсить да ещё и проверять на соответствие xsd! Короче осадок остался один — это та же корба, только переписанная под xml со всеми вытекающими последствиями.
Для веба пользуйтесь REST, люди докторские не просто так получали за это (Рой Филдинг кажется). Для некоторых не очень сложных случаев вполне можно использовать и вебсервисы, хотя новое что-то я бы под них не стал сейчас создавать, их время прошло.
XML-RPC: Пожалуй самый старый подход — данные в виде XML передаются посредством RPC (remote procedure call). Это вообще появилось с появлением XML, просто его стали использовать как формат для передаваемых параметров удалённых функций. Заметьте, что HTTP тут вообще ни при чём, это просто неточная интерпретация терминологии. И кстати, RPC как правило требует permanent connection между клиентом и сервером.
REST: Тут действительно оптимально используется протокол HTTP, со всеми глаголами. Короче, нет слов — всё очень красиво и эффективно.
SOAP: Это всего лишь стандартизированный формат передаваемых данных. Тот же XML, но с предварительно описанными в XSD типами (XSD можно вставить прямо в WSDL), сообщениями, binding-ом сообщений на методы, структурированием методов в группы и описанием собственно WebService-а. SOAP всегда ходит по какому-нибудь протоколу. У вас подразумевается HTTP, но мы однажды его пускали даже поверх Tibco, надо было :) В целом SOAP описывает то, что из себя представляет SOAP envelop и вообще, WebServices — это XML-пародия на ставшую в своё время черезчур сложной Corba. Вспомните, в корбе у нас IIOP — в вебсервисах SOAP, в корбе IDL — в вебсервисах WSDL…
В своё время я участвовал в стандартизации WS-Security в OASIS, там даже никаких токенов секурити тогда ещё не было.
А вот REST — действительно красиво и удобно.
--- begin ---
options IPFIREWALL
# We comment this because it works OK and no debugging is needed
#options IPFIREWALL_VERBOSE
#options IPFIREWALL_VERBOSE_LIMIT=100
options IPDIVERT
options IPFIREWALL_FORWARD
# FYI: for kernel nat:
options IPFIREWALL_NAT #ipfw kernel nat support
options LIBALIAS
---- end ----
Кажется в этом месте я ничего в последнее время не менял… Разумеется если ядерный nat не нужен — можно выкосить последние две строчки.
DUMMYNET и IPSTEALTH не пользуюсь. Подозреваю что IPDIVERT мне не нужен (остался со времён не-ядерного ната), посмотрю попозже и пожалуй уберу.
Почитать можно как всегда man ipfw, секцию NAT.
Handbook немного устарел по этой теме, но вот тут можете почитать как это делается.
Сам vim пользуюсь только для правки конфигов, предпочитаю для разработки использовать emacs (не знаю, лучше он или хуже чем vim). Тоже поначалу адаптировался некоторое время, но зато потом он просто становится гармоничным продолжением рук, можно кодить хоть на чём быстро и не отвлекаясь на ненужные рюшечки с свистульки.
Для тех, кто сомневается переходить ли с предыдущей версии на 8-ку могу посоветовать посмотреть стоп-лист багов на /releng страничке. Если то, что там написано вами не используется, то вполне можно попробовать «пересоздать мир» :)
В общем, если всё делать неторопясь, вдумчиво, отдавая себе отчёт что и зачем вы делаете (BSD style кстати), то за викенд вполне можно подняться до RELENG_8.
Из того, что запомнилось с этого апгрейда мне лично:
— wifi интерфейсы теперь всегда оборачиваются в wlan (даже если они learned by if_bridge!) => нужно немного подправить /etc/rc.conf и ещё где там у вас жёстко указано имя интерфейса.
— usb устройства теперь имеют вид ugenX.Y => тоже может кое-где конфиги подправить нужно будет.
— есть несколько устаревших options в файле конфигурации ядра, но make вам это сам сообщит, не торопитесь в этом месте, почитайте UPDATING, посмотрите конфиги GENERIC и NOTES.
В целом всё взлетело без единого чиха, я как всегда остался доволен надёжностью и предсказуемостью системы.
Те, кто сомневается переходить ли на FreeBSD с другой системы — убеждать не буду, если вам интересно — пробуйте.
Вы ошибаетесь и рассуждаете слишком поверхностно (только не обижайтесь пожалуйста)
Да, тема похоже для многих тут наболевшая :)
Правда споры в основном идут не о том — большинство отстаивают то, что лучше знают. Чёрт побери, столько шуму, а по сути — так несерьёзно…
Вот начиная с задач в десятки тысяч транзакций в секунду вся эта шелуха что в статье описана и осыпается, начинается реальный technical challenge.
С практической точки зрения представленный хлам никуда не годится. Я имею ввиду что каждый программный модуль в отдельности конечно вещь стоящая, но вот всё вместе оставляет ощущение… хмм… некоторого бардака.
По идее нужно плясать от конкретной задачи, представить архитектуру, выяснить требования к каждому модулю, а уж затем рассуждать что они будут из себя представлять. А у вас — подход микрософт, подход гугл… Да грамотный архитектор вообще об этом не думает, какие у кого подходы! Он аргументы в пользу того или иного решения проверяет, proof of concepts мастерит. А эти решения ему опыт его даёт.
Универсальную архитектуру при жёстких требованиях не сделать — то там косяк вылезет, то там модуль отвалится. Видеть надо всю систему глобально, не упуская конечную цель.
И ещё, реально работающая высоконагруженная система, решающая определённую задачу, она выверяется годами. Речь конечно не идёт о случае когда вы копируете чью-то исходную задачу — тогда конечно её решение кто-то за вас уже выверил.
Мне доводилось участвовать в разработке подобных комплексов. Чутьё приходит с годами серьёзного опыта, причём от задачи к задаче решения могут быть разные в силу специфики контекста.
Эх, тема настолько обширная, что тут можно рассказывать очень долго…
Желаю вам дело это не забрасывать, ведь именно там, где мы решаем трудные задачи, мы обогащаем свой опыт бесценными знаниями.
«Иногда лучше молчать, чем говорить» (с)
В данном случае, мошенник уже понял, что ваш клиент при таком раскладе будет вынужден иметь дело с милицией, сами вы ему почему-то помочь не захотите. Извините, но многие проходящие мимо поймут вас именно так.
Вам конечно видней, но может быть вы сообщите мою идею своему начальству? Или у вас за такое наказывают? 8-/
В этой истории странным мне кажется поведение господ из Яндекса — пассивное, безразличное к имиджу своей компании. Вон уже слышатся голоса, что ВебМани лучше, а карточки и подавно…
Блин, дарю Яндексу идею — включитесь АКТИВНО в распутывание этой детективной истории! Покажите что вы технически компетентны, что вам небезразличны ваши клиенты! Цена вопроса — 10000 рублей, зато какая вашему бизнесу будет реклама!
Меня бы такая история включила сразу, а вы — «пишите заявление», «идите в милицию»… Вы осознаёте что такой подход принесёт мало пользы?
Пока что от этой истории выиграют ваши конкуренты, но я бы на вашем месте повернул всё в вашу пользу. И в пользу вашего клиента конечно…
PS Автор молодец, искренне желаю ему успешного разрешения этой проблемы и спасибо за тему, которая затрагивает тут многих людей.
PPS Тащусь от реалий российского бизнеса :)
FYI в squid за это отвечает «header_access X-Forwarded-For deny all»
Обычный лямбда-пользователь, который поведётся на «0$» скорее всего быстренько перейдёт на по-настоящему бесплатный офисный пакет. А впечатление которое останется — «опять MS не довела до ума свой продукт»…
Хотя… зачем это всё нужно, открываем msdn и делаем, что тут нового?
Тоже кстати интересная вещь, я так с помощью него тоже слушал одно время музыку прямо на работе :)
Вот уж где действительно клиент-серверная архитектура в действии :)
PS
Есть ещё QTSS (ака DarwinStreamingServer), пробовал с него сделать дома просмотр фильмов, но приходится всё конвертировать в mp4, в общем бросил эту затею.