В свое время (1996й год) я написал (и Компьютерра опубликовала :) статью про веб-серверы, где упоминал про самодельный веб-сервер. 80 строк на Форте. На Смолтолке тоже около того. Не самые минималистические на уровне helloworld, а достаточные для раздачи файлов. Java тогда еще только-только появилась, на ней не пробовал. Теперь вижу, что минимум 70 строк на Java :)
Когда-то в древности каждый программист начинал с того, что писал собственный текстовый редактор. Собственный веб-сервер — хорошее упражнение для современного программиста :)
В винде вместо sendfile есть аналогичная функция TransmitFile. Так вот она асинхронная, т.е. возвращает управление сразу после вызова, и далее работает где-то в системных воркерах. Т.е. ждать ничего не надо. Знаю точно, использую несколько лет. Для отдачи статических файлов хорошо подходит.
Собственный шедулинг все равно должен как-то накладываться на ядерный (т.к. у ОС другого нет :). И не факт, что два шедулера лучше одного. В винде (начиная с Win2000) есть такая штука как IO completion port, который может использоваться как для асинхронного в/в, так и для создания пула рабочих потоков, т.е. эти вещи в общем случае взаимосвязаны и в системном планировщике.
Нет. Вместо процессов-воркеров создавать потоки-воркеры (в Windows например спец-средства для этого есть).
Кстати, в создании потоков тоже ничего страшного нет. Только не на каждый запрос, а на каждый коннект. В HTTP/1.1 активно используется Keep-Alive (по умолчанию), в одном коннекте к одному сайту могут десятки/сотни http-запросов передаваться. Для небольших сайтов это наиболее экономный режим — если запросов мало, то никакие воркеры память не занимают.
Пример сервера с сертификатом GoDaddy:
https://secure.snop.ru/
проверил сейчас с IE8, FF3.5,Opera10,Safari4,Chrome2 (под Вистой) — никто не ругается.
И это при том, что на сервере используется новая (относительно) фишка SSL — SNI (http://en.wikipedia.org/wiki/Server_Name_Indication), т.е. поддержка нескольких SSL-серверов на одном IP. Собственно для испытания этой возможности сертификат там и поставлен (а сервер на базе Eserv/4).
В XP SNI не работает, и в линуксах не во всех, соответственно клиент не будет при установке SSL-соединения передавать имя хоста, поэтому сервер будет давать другой сертификат (который по умолчанию для того IP), и браузер будет ругаться.
Я ставил на подобную машину (мать asus с nVidia nForce, встроенное видео, Athlon 64 X2, два гига памяти) и Windows 7 beta (зимой), и недавно Windows 7 релиз, все нормально.
Тем не менее, если на один и тот же ноутбук ставить Linux и Windows XP, то XP живет на батарейках процентов на 20 дольше. Windows 7 может и выигрывает у Windows Vista, но почему-то проигрывает Windows XP, не смотря на все эти хитрые таймеры и прочие оптимизации. Поэтому с XP предпочитают не сравнивать :)
Так же как и в TCP, повторная передача будет нужна только при потере пакетов данных или пакетов подтверждений. По описанию ( www.bittorrent.org/beps/bep_0029.html ) видно, что потеря|непотеря тоже определяется по таймаутам (и вы пишете «через некоторое время»). Т.е. проблемы будут те же, что и в TCP, и решаются также. Порядок передачи действительно не важен (и это основное отличие от TCP), но есть «окна», и обрабатываются они последовательно, значит таки порядок всплывает обратно, просто чуть в другом месте.
Да во всех scm есть собственные встроенные серверы с собственным протоколом. Но я как раз о случае, когда их использовать нельзя или невозможно. А HTTP всегда доступен, и с ним работа у Git'а самая удобная, imho.
«При этом, если посылающий сидит на широком канале, а принимающий — на модеме, то первый сразу отправляет большой блок данных, который может быстро дойти до провайдера второго, и потихоньку просачиваться в модем. В это время первый, не получив подтверждения о получении, перешлёт часть кусков заново. Ещё раз, и ещё, в результате магистраль провайдера оказывается забита этой ненужной перепосылкой. Одна из основных целей uTP — устранить эту лишнюю нагрузку на провайдеров от P2P-трафика.»
Описанное явление называется congestion. TCP собаку съел на борьбе с этими затыками/ лишними перепосылами. В каждой очередной версии ОС (что Windows, что Linux) что-нибудь подкручивают, чтобы TCP автоматически подстраивался под пропускную способность каналов. Можно сказать, что проблема эта в TCP решена весьма добротно. Неужели разработчики торрент-клиентов могут переплюнуть в этом разработчиков TCP/IP-стеков в ОС?
Чем еще Git удобнее чем SVN — это лучшей совместимостью с WebDAV-серверами (когда нужно не через «родной» протокол запускать обмен, а по HTTP). Для Git инструкция по дружбе с веб-сервером умещается в несколько строк — www.eserv.ru/GitEservHowTo
Но Линукс с таким (плохим) кодом становится лучше (для кого-то), поэтому пусть будет. А кому от этого плохо — может не использовать. В конце-концов линукс работает на процессоре, код которого (схема, микропрограммы) Intel не раскрывает — и ничего, как-то справляемся ;)
Да, ненависть (к чему угодно) вообще является болезнью.
Ссылку на этот комментарий Линуса надо сохранить и предъявлять всякий раз для охлаждения слишком горячих голов. По крайней мере тех из них, для которых Торвальдс — авторитет.
Клевещут. Обычный перебой в связи (из-за перегрузок, вызванных повышенным вниманием к их сайтам из-за выборов) выдают за фильтрацию.
Самое смешное здесь в том, что внутри Ирана этот сбой могут объяснить DDoS-атакой со стороны вражеских государств, и в подтверждение предоставить тот же самый график!!! (посмотрите на пики перед отключением!)
Аналогичные перебои в работе своих сетей эстонцы и грузины объясняли именно такими атаками, хотя это были не атаки, а просто более высокая нагрузка, на которой софт и железо ранее не тестировались.
Да, интересное чтиво (как и интересный спор в хабре :) время крадёт. Мне всегда помогает такой способ: я сам себе объявляю мораторий на «непрофильное» чтение, на посещение таких-то сайтов, даже на просмотр новостей — до тех пор, пока не завершу заданный этап в проекте (обычно релиз новой версии или большой фичи). Иногда месяца по три в такой отключке от мира, погружен в работу. О том, что в мире делается, узнаю только в беседах за обеденным столом (у меня дома не все в отключке :).
Если самозапрет не получается, то, говорят, что помогает «официальное заявление» — обещание (кому-нибудь, перед кем не хочешь выглядеть пустобрёхом) не делать того-то, пока не доделаешь то-то.
Откуда вывод о том, что скайп ничего не крадет? Всё зашифровано, и мы можем только ВЕРИТЬ, что ничего не крадётся. А с какой стати нам вдруг верить, что авторы KaZaA, критикуемые за spyware/malware (см.цитаты выше) вдруг стали белыми и пушистыми в случае со Скайпом? Если они выросли, образумились, стали белые и пушистые — почему не откроют протокол? Никакой безопасности не вредила известность алгоритма RSA, открытость протоколов SSL/TLS/SSH и т.д., а как раз наоборот — позволяет находить дыры и повышать безопасность, повышать доверие к этим методам.
А раз шифруют, то у меня как раз все основания подозревать, что дело может быть не чисто.
Причины закрытости протокола, конечно, могут быть и более тривиальными — защита от конкуренции, защита от судебного преследования за использование кода GPLных сырцов в закрытых продуктах, и т.п. Мы ничего не знаем, и можем лишь гадать, и верить в ту версию, которая нам больше нравится. Например так — сегодня этот ботнет передает голосовой трафик, завтра нелегальный софт, послезавтра спамит, в пятницу DDoS-атакует, в субботу стирает винду, и концы в воду :)
Исходная тема обсуждения — законно или незаконно. Скайп использует твой компьютер не только в твоих, но и в чужих целях. Не предупреждая тебя об этом. ЭТО незаконно.
А заметит/не заметит, потянет/не потянет — это другой вопрос. Но можно точно сказать, что если при установке предупредить пользователя, что «мы будем тебя использовать в таких вот позах», то супернодов станет на порядок меньше. И если бы такое предупреждение изначально было в Скайпе, то скорее всего мы и слова бы такого не знали — не вышел бы он за пределы прибалтики, т.к. без супернодов (бесплатного ботнета) владельцы скайпа не потянули бы такую нагрузку своими собственными серверами. В общем, законного пути «подняться» у них фактически и не было.
Я уже писал об этом выше, и ссылку я ту же самую дал :). Любой читатель этого соглашения поймёт фразу «передачи данных между тобой и третьими лицами» как передачу его звонков между ним и каким-то третьим лицом (кому он звонит). А на деле кроме такой передачи производится и передача данных между никак не связанными с тобой третьими лицами через твой компьютер, т.е. чужих разговоров через тебя. Об этом ничего не написано.
«Как можно запретить убийства — ведь человеческое тело такое слабое, куда не воткни гвоздь, везде воткнётся, невозможно же его всего в броню заковать»?
Запрещать (не убий) и фильтровать (принудительно не допускать убийства) — очень разные вещи ;)
Когда-то в древности каждый программист начинал с того, что писал собственный текстовый редактор. Собственный веб-сервер — хорошее упражнение для современного программиста :)
Кстати, в создании потоков тоже ничего страшного нет. Только не на каждый запрос, а на каждый коннект. В HTTP/1.1 активно используется Keep-Alive (по умолчанию), в одном коннекте к одному сайту могут десятки/сотни http-запросов передаваться. Для небольших сайтов это наиболее экономный режим — если запросов мало, то никакие воркеры память не занимают.
https://secure.snop.ru/
проверил сейчас с IE8, FF3.5,Opera10,Safari4,Chrome2 (под Вистой) — никто не ругается.
И это при том, что на сервере используется новая (относительно) фишка SSL — SNI (http://en.wikipedia.org/wiki/Server_Name_Indication), т.е. поддержка нескольких SSL-серверов на одном IP. Собственно для испытания этой возможности сертификат там и поставлен (а сервер на базе Eserv/4).
В XP SNI не работает, и в линуксах не во всех, соответственно клиент не будет при установке SSL-соединения передавать имя хоста, поэтому сервер будет давать другой сертификат (который по умолчанию для того IP), и браузер будет ругаться.
А многопоточности там нет что ли? Тогда AIO в конечном итоге все равно потребует увеличения к-ва процессов-воркеров.
Описанное явление называется congestion. TCP собаку съел на борьбе с этими затыками/ лишними перепосылами. В каждой очередной версии ОС (что Windows, что Linux) что-нибудь подкручивают, чтобы TCP автоматически подстраивался под пропускную способность каналов. Можно сказать, что проблема эта в TCP решена весьма добротно. Неужели разработчики торрент-клиентов могут переплюнуть в этом разработчиков TCP/IP-стеков в ОС?
Ссылку на этот комментарий Линуса надо сохранить и предъявлять всякий раз для охлаждения слишком горячих голов. По крайней мере тех из них, для которых Торвальдс — авторитет.
Самое смешное здесь в том, что внутри Ирана этот сбой могут объяснить DDoS-атакой со стороны вражеских государств, и в подтверждение предоставить тот же самый график!!! (посмотрите на пики перед отключением!)
Аналогичные перебои в работе своих сетей эстонцы и грузины объясняли именно такими атаками, хотя это были не атаки, а просто более высокая нагрузка, на которой софт и железо ранее не тестировались.
Если самозапрет не получается, то, говорят, что помогает «официальное заявление» — обещание (кому-нибудь, перед кем не хочешь выглядеть пустобрёхом) не делать того-то, пока не доделаешь то-то.
А раз шифруют, то у меня как раз все основания подозревать, что дело может быть не чисто.
Причины закрытости протокола, конечно, могут быть и более тривиальными — защита от конкуренции, защита от судебного преследования за использование кода GPLных сырцов в закрытых продуктах, и т.п. Мы ничего не знаем, и можем лишь гадать, и верить в ту версию, которая нам больше нравится. Например так — сегодня этот ботнет передает голосовой трафик, завтра нелегальный софт, послезавтра спамит, в пятницу DDoS-атакует, в субботу стирает винду, и концы в воду :)
А заметит/не заметит, потянет/не потянет — это другой вопрос. Но можно точно сказать, что если при установке предупредить пользователя, что «мы будем тебя использовать в таких вот позах», то супернодов станет на порядок меньше. И если бы такое предупреждение изначально было в Скайпе, то скорее всего мы и слова бы такого не знали — не вышел бы он за пределы прибалтики, т.к. без супернодов (бесплатного ботнета) владельцы скайпа не потянули бы такую нагрузку своими собственными серверами. В общем, законного пути «подняться» у них фактически и не было.
Запрещать (не убий) и фильтровать (принудительно не допускать убийства) — очень разные вещи ;)