Новогоднее RDP

Скоро новый год, а значит выходные, т.е. к серверам лучше не прикасаться, а если прикасаться, то аккуратно. Естественно, Microsoft всех приучило, что самый простой и ненапряжный способ это сделать - RDP (нет, конечно, PowerShell рулит и бибикает, но назвать этот способ простым, как-то язык не поворачивается).

Итак, RDP живёт, проблем вроде бы нет, но... в один прекрасный момент вы обнаруживаете следующую картину, которые можете наблюдать продолжительное время без видимых результатов.

Другими словами, при попытке подключения — RDP тупит, а потом идёт отлуп с пространными объяснениями, что всё плохо.
Вы дома, сервер далеко, к нему не подойти и не пнуть ногами. Подключиться — не удаётся.
Практика показывает, что это частое явление при разрывах сети. Т.е. кроме разрыва соединения, ещё появляются такие шикарные эффекты. Причем страдают обычно 8-ые винды (т.е. Windows Server 2012 и 2012 R2)
Что в этом случае можно сделать?

Для начала, конечно же выполнить пункт номер 0 — иметь пути отхода и дырку в фаирволле. Причём делать это по-возможности всегда. Т.е. у вас всегда должно быть как минимум 2 пути подключения к серверу (например через рабочий компьютер и через другой сервер), и желательно на определённые IP иметь хороший список открытых портов для этих дружественных компов. Винда это вам не Linux, тут одним SSH не обойдёшься, особенно когда так тупит RDP!

Вариант первый, банальный и неинтересный:

shutdown /m \\server /r /t 1

Отправляем компьютер в ребут... очевидно и неинтересно. Надо идти другими путями. Другие пути заключаются в том, что надо бы перепустить службу Remote Desktop, которая зовётся TermService.

Тут 2 варианта:

sc \\server restart TermService (оцените синтаксис команды относительно предыдущей)

Или же, с помощью мышки: mmc.exe, добавить остнаску, службы, другой компьютер, перезапуск.

Но, тут как всегда нас ждёт сюрприз... в 90% случаях служба зависнет и не захочет останавливаться. Так что придётся добивать её ногами. Битьё усложняется тем, что она висит в процессе svchost.exe (благо обычно на нужном ничего полезного нет).

Так что

tasklist /s server /svc | findstr TermService (оценили синтаксис?)
taskkill /s server /pid 123456

Ну и запускаем службу. Вроде просто и очевидно, но как всегда лезут нюансы: если у нас плохо с логином и паролем (а мы дома, а не в домене), то получим отказ в доступе. Некоторые команды имеют возможность указать логин с паролем, некоторые используют существующее соединение (net use \\server\c$ - получим замечательное подключение и для управления), некоторые просто отказываются работать.

Можно применить PowerShell, создать сессию на сервер и там всё сделать, но ведь его надо настроить... добавить доверие... в общем если вы не занимаетесь этим специально, работать не будет.

Так что, если всё плохо и ничего не работает, то придётся ползти в сторону Sysinternals, а именно PsTools, и через psexec уже всё делать. Что удивительно, работает это гораздо надёжнее, чем встроенные средства системы. Даже если не разбираться, можно написать

psexec \\server tasklist /svc

И получить тот же результат (да, мне лень изучать другие команды из этого набора ).

Собственно, зачем я это написал? Вроде очевидные вещи. Да в общем-то с двумя простыми целями: в очередной раз поныть на винду, и показать, что если что-то не работает, можно всё-таки обойтись без перезагрузки.

UPD: Спустя время, надо бы добавить ещё пару команд, которые помогут решить подобную проблему. Ибо у Microsoft всё устроено очень сложно, половина команд может работать, а другая половина не работать с дурацкими сообщениями вида (не шутка):
Couldn't access server:

The operation completed successfully.

Соответственно, tasklist /svc в нашём случае можно заменить на

sc queryex TermService

А вот с taskkill посложнее. Может прокатить скрипт на PowerShell

Invoke-Command -ComputerName server -ScriptBlock {Stop-Process -Id 123456 -Force} -Credential DOMAIN\user

Interstellar, впечатления

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

Соответственно, я хочу пересказать сюжет, комментируя некоторые моменты, а если кто хочет со мной поспорить, то вэлкам в комментарии. Я действительно допускаю, что я мог чего-то не понять.

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

Дальше будет много спойлеров, так что, если вы ещё не смотрели данный фильм — не рекомендую читать.

Итак, поехали...

Завязка истории следующая: Земле кирдык, все жрут одну кукурузу, но поскольку она у всех сидит в горле, то периодически сжигают посевы. Хотя ладно, буду чуть серьёзнее — постепенно все растения заболевают и дохнут, чтобы другие не болели — посевы периодически сжигают. Все ресурсы человечества брошены не на борьбу с болезней растений, а не выращивание ещё большего их количества. Также, постоянно случаются пылевые бури (слава богу, не радиоактивные), и доблестным американским фермерам, живущих в насквозь дырявых халупах приходится постоянно вытирать песок.
Да, этот мир весьма странен, в нём летают беспилотные самолёты (причём летают 10 лет и больше, на солнечных батареях), комбайны управляются автоматикой, при этом все живут в халупах, ездят на древних пикапах и пользуются унылыми ноутбуками.
У главного героя есть сын, у которого из способностей только возможность стать фермером, и дочь, которая видит призраков. Главный герой одновременно и пилот, и инженер, и мегафизик, который запросто считает баллистические траектории и гравитационные манёвры. Ну а сейчас работает фермером и ремонтирует комбайны.

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

По ходу дела, дочери призрак сообщает банарным кодом некоторые координаты, и главный герой сразу это определяет. Мазафака, запишите координаты двоичным кодом, посмотрите что получится, а потом попробуйте собрать это назад. Ну да ладно. ГГ ведь очень крут! Он бросает всё и ломится по указанным координатам, где застаёт сверхсекретную базу NASA. Где его сразу же берут пилотом на космический корабль, у которого цель найти планеты, пригодные для жизни, чтобы срулить нафиг из этой планеты. Т.е. по факту, получается, что ресурсов у населения планеты Земля дохрена, что они могут отправить толпу людей в другую галактику, лишь бы не жрать кукурузу. Ну и делать всем точно нехрена, потому что все знают, насколько ГГ крут, правда позвонить по телефону ему и пригласить — как-то не догадались.

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

В общем, быстренько все собрались и полетели. ГГ, девушка учёный, бородатый негр и ещё один дядька (тоже учёный). Прилетели они на первую планету, и случайно оказалось, что она находится рядом с чёрной дырой, что на орбите время течёт нормально, а если спуститься, то замедляется. И час, проведённый на планете, равен 7 годам на Земле. Ну а ещё, из иллюминатора не видно, что там происходит. В общем, нашим героям делать нечего, они спускаются на планету, и узнают, что там сплошной океан (и почему в кораблях не делают иллюминаторы?), а предыдущая команда разбилась, и только робот сообщает об успешном приземлении. Твою мышь... Надо было проделать такой путь, чтобы догадаться до того, что догадались герои!

Ладно, минус один участник команды, минус 23 года на Земле, три седых волосинки в бороде у негра, который 23 года тусил на корабле и жрал кукурузу. Никаких психических отклонений нет, на землю отправить ничего не смог (предыдущая команда смогла — эти нет, для пущего сюжета). Герои вернулись на корабль, и стали слушать входящие послания. На Земле люди весьма умные, поэтому из всех вариантов: корабль разбился, корабль засосало в чёрную дыру, команду съели рептилоиды, выбрали самый вероятный: команда просто решила срулить с Земли, ибо в космосе веселее. Ооок...

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

По пути, ГГ отправился в чёрную дыру, вернулся в прошлое в комнату дочери, начал изображать призрака, а потом азбукой морзе на стрелке часов передал магические формулы чёрной дыры. Извините, но тут я охренел конкретно. По-хорошему, на этом бы и закончить всё, но нужен супер хеппи-энд, поэтому герой вываливается из чёрной дыры, его находят на огромном космическом корабле, который построили с помощью его мегаформул, ну и под конец он ворует истребитель и летит спасать девушку-ученого, которая нашла-таки планету, пригодную для жизни. Куда и зачем в это время летел большой космический корабль, я как-то не уловил. Всё, конец, все счастливы.

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

---

И вот после этого, мне пытаются рассказать, какой это крутой фильм, и какая там глубокая философия. Я вот честно, целый день думал о фильме, пытался что-то выжать, не получилось ничего. Единственное светлое пятно в фильме — боевой нечеловекоподобный робот с чувством юмора, исполняющий роль говорящего R2D2.
Фильм при этом слегка отдаёт Космической Одиссей, но почему-то у Кубрика получилось сделать длинное, затянутое повествование без какого-либо действия очень интересным, тут я не увидел этого. 

Android. Часовые пояса. 2014 год.

UPD: Дальнейший анализ показал, что на некоторых телефонах возможно чуть более простое обновление файлов, не перепрошивкой, а просто любым системным приложением. К сожалению, обновляют таким образом очень мало производителей (Samsung, и, местами, HTC), что оставляет пост в силе.

Заканчивается 2014-ый год, в России опять переводят время, все телефоны опять начнут страдать фигнёй и путаться в показаниях.Меня удивляет, что несмотря на многочисленные пинки и тычки (а часовые пояса постоянно кто-то меняет, недавно, например, хорошо отличились Чили и Египет), в Андроиде не только не хотят подумать над автоматическом обновлением часовых поясов, даже не хотят нормально решить проблему их установки в новых прошивках. Например, у меня сейчас телефон с прошивкой недельной давности, в котором стоят зоны от 2013 года!

Немного технической информации для понимания механизма: практически во всём мире (кроме Microsoft, конечно же), информация о часовых поясов берётся из полуофициальной базы TZ Database. Я говорю полуофициальной, потому что, несмотря на контролирование этого файла IANA, по факту изменения в него вносятся обычными людьми. Т.е. я узнал, что в России будут новые часовые пояса, написал письмо и файл обновили. Никакого официоза (конечно, я надеюсь, что эту информацию хотя бы проверяют по новостям).

Эта база имеет формат ГодБуква, где год — это год обновления базы, а буква — порядковый номер обновления. На данный момент это 2014h, следующая будет 2014i или 2015a, в зависимости от того, когда выйдет.

База представляет собой набор текстовых файлов определённого формата, которые под *nix компилируются в специальные бинарные файлы с правилами. Текущая зона вешается симлинком на один из этих файлов. Например, на Europe/Moscow.
В других системах, эта база может иметь другой вид. Например, на андроиде до версии 4.3, это было 3 файла, но с версии 4.3 — стал уже один. Значит зачем-то программисты подбирались к этому коду, но совершенно не подумали о том, что он может устареть.

И вот эта глупейшая ситуация, меня убивает. За столько лет существования Android, совершенно не думать о том, что данные могут меняться. Уму непостижимо. Я понимаю, американцы, которым плевать на весь окружающий мир, но ведь разработчики есть из разных стран, тем не менее, ничего сделано не было.

Конечно, если у вас есть рутовые права на телефоне, вы можете воспользоваться программой TimeZone Fixer, которая делает ровно одну вещь: копирует 3 файла в нужную папку. Эти 3 файла решают все проблемы. Но к сожалению, программе нужен рут, что не у многих есть. Вот так приходится работать за ленивых гугловских программистов, которым гораздо веселее в 7-й раз перерисовать иконки, чем сделать что-то полезное для людей. 

Про мышей. Компьютерных

Я очень люблю различные мышки. Собственно, это один из двух основных инструментов работы за компьютером, который постоянно в руках. Поэтому мышь должна быть удобной и приятной на ощупь. К тому же, я уже много лет предпочитаю беспроводные мыши. И заметил следующую особенность — последние несколько лет технологии мышей практически не развиваются. Что весьма странно и печально.

Например, я 5 с лишним лет купил самую модную мышь от Microsoft — Sidewinder X8, у которой на тот момент (да и до сих пор) были весьма модные и оригинальные решения: небольшой экран, показывающий статус (например заряд и текущий DPI), металлическое колесо прокрутки, сменные ножки, подключаемый зарядный провод на магнитике. Ну так вот, она до сих пор работает. Чуть пообтёрлась но работает абсолютно также, как и раньше. Но т.к. я любитель мышей, я периодически поглядываю на то, что можно заменить. А проблема в том, что за эти 5 лет — полная тишина.
Logitech по-прежнему клепает грустые Performance MX мыши, Mad Catz делает совершенно безумную R.A.T.9, которая очень круто выглядит но по факту почти не работает от батареи, а грязь забивается куда только можно. У Razer и то, только Mamba 2012-ого года без всяких чудес, но за приличные деньги, и Ouroboros — за неприличные. Редкие оригинальные решения типа Microsoft Arc Mouse занятны для поездок, но не для работы. 

Т.е. грусть и тоска, хочется потратить деньги, а не на что.

И тут, совершенно случайно, во время поисков в интернет-магазине чего-нить для добития суммы покупки, обнаруживаю A4Tech Bloody R8. Не буду вдаваться в маркетинговый bullshit, но A4Tech, действительно в очередной раз придумала что-то новое. Во-первых, это металлические ножки (обычно тефлон или что похуже). Во-вторых зарядка от обычного microUSB, т.е. даже спец-кабель не нужен, а приёмник вставляется внутрь мыши для переноски. Ну а в третьих, это всё стоит 1000 руб! При этом, она светится разными цветами, есть всякие мега-опции по уменьшению задержек и увеличению точности, и прочая белиберда, которая есть в той или иной мере у всех. Но 1000 руб. за мышь со встроенной батарейкой, модными ножками и приятным колёсиком — это очень круто.

А ещё более круто, что какая-то китайская компания делает больше новшеств в мышах чем все остальные вместе взятые. Например, у них всю жизнь было самое лучшее ребристое колесо (среди дешёвых мышей), которое никогда не разваливалось (привет Genius и Microsoft). Они делали мыши с двумя колёсами (очень круто), с софт-тач пластиком, с резинкой сбоку для удобного хвата. Делали мышки с питанием от коврика, делали беспроводные мыши с четырьмя аккумуляторами, зарядником от USB за какие-то смешные деньги (я до сих пор использую эти аккумы в различной технике). Они придумали гениальную MOP-35, мелкая мышь, которая была у огромного количества народа. Потому что она очень милая. Они развлекались с маленькими дырками для сенсора, чтобы было меньше пыли, делали дополнительные кнопки для двойного клика (если приноровиться, очень полезные). В общем, удивительно, сколько всего они напридумывали. Ну и вообще, у них есть одна из лучших для меня форм мышей.

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

Очень хорошо, что есть такая компания, которая периодически делает что-то действительно интересное и если хочется что-то для души, я знаю куда смотреть.

Про мобильный интернет

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

• МТС даёт за 250 руб/месяц 3Гб интернета по СуперБиту, действующему по всей России (с неявными условиями действия, возможно 30 руб. в сутки за межгород)
• Мегафон за те же 250 руб/месяц уже даёт 5Гб интернета, но только в домашнем регионе (+10 руб/сутки за межгород)
• Билайн за те же 250 руб/месяц (как бы случайно совпало) даёт те же 5Гб интернета, но зато действует по всей России без ограничений
• СМАРТС за 200 руб/месяц даёт полный анлим 2G интернета, что реально позволяет выкачать аж 200Мб. На большее он не способен.

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

А так получается, что в нашей деревне самый лучший и без вариантов — Билайн, и даже нет ни одного факта смотреть на других провайдеров (по качеству самого интернета претензий особых тоже нет). 

Ну, а МТС имеет неясные условия, но похоже что самый дорогой.

Использование быстрых алгоритмов сжатия в потоковом режиме

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

Начнём по-порядку.

• zlibnet — считает метод Flush сигналом для записи финального блока, что приводит к некорректному поведению. Надо чинить (а лучше переписать самому, где там мой блокнотик?)
• SharpCompress — любитель вызывать метод записи с длиной в 0 байт, что, имхо, весьма неаккуратно. Может на некоторые потоки создавать бессмысленную нагрузку
• SharpZipLib — никаких нареканий
• Встроенный GZip — буфер в 8Кб, полностью игнорируется Flush, оказывается для потоков его использовать нельзя.
• Snappy — блочный алгоритм, блоки с префиксом и контрольной суммой, что накладывает отпечаток на возможностях
• Snappy for .NET — нет реализации стримов, пропускаем
• Snappy.NET — блок прибит гвоздями в 64Кб, Flush вызывает запись независимого блока. Т.е. частый флуш приведёт к потере сжатия и увеличению объёма
• LZ4 — тоже блочный, при уменьшении блока резко падает степень сжатия, поведение аналогично Snappy. В реализациях (lz4-net и LZ4.NET) проблем не обнаружил (кроме самого факта с проблемами потока). Из хороших новостей — потоковое API для LZ4 разрабатывается (прямо в тот момент, как я пишу этот текст). Оно ещё не стандартизировано, но шансы есть, что будет всё круто.
• LZF — я его достал с дальнего ящика и смотрю на него. Его особенность, что сжатие позволяет писать данные хоть по байту (и читать сжатые по байту). Правда исходные данные пока выглядят блочными, но думаю это можно будет поправить, если поисследовать алгоритм. 

Выбор быстрых алгоритмов сжатия под .NET

Для начала, пара таблиц для привлечения внимания:

Быстрый компьютер:

MemCopy:         1561.050       1709.7218        100.000%
GZipStd:           66.736        221.6318          6.335%
#ZipLib.Gzip:      52.800        136.0018          6.358%
zlibnet:          100.572        466.2888          6.500%
SharpComp.GZip:    52.568        154.7598          6.501%
Snappy.Net:       970.382        944.8468         13.312%
SnappyforNet:     997.337       1795.2078         14.499%
lz4net/CC:        485.191       1122.0048         10.740%
lz4net/MM:        997.337       1158.1988         10.740%
lz4net/N:         535.883       1122.0048         10.740%
lz4net/S:         386.066        690.4648         10.740%
lz4net/HC:         42.794       1282.2918          7.751%
LZ4.Net:          997.337       1158.1988         10.896%
QuickLZ:          460.310        528.0028          8.032%
LZO_1X   :       1683.082       1561.0508         11.824%
LZF     :         272.001        398.9358         13.882%

Медленный компьютер:

MemCopy:          394,551        394,5518        100,000%
GZipStd:           18,006         50,4278          8,738%
#ZipLib.Gzip:      16,137         45,2198          6,358%
zlibnet:           31,086        105,6008          6,500%
SharpComp.GZip:    18,356         46,6898          6,501%
Fail Snappy.Net: Инициализатор типа "Crc32C.NativeProxy" выдал исключение.
SnappyforNet:     260,175        432,5808         14,499%
Fail lz4net/CC: Ссылка на объект не указывает на экземпляр объекта.
Fail lz4net/MM: Ссылка на объект не указывает на экземпляр объекта.
lz4net/N:         218,928        228,6898         10,740%
lz4net/S:         120,484        141,9148         10,740%
Fail lz4net/HC: Ссылка на объект не указывает на экземпляр объекта.
LZ4.Net:          234,668        274,0778         10,896%
QuickLZ:           60,445         65,0448          8,032%
LZO_1X   :        374,001        505,6928         11,827%
LZF     :          44,880         60,3438         13,882%

Это я тестировал различные реализации алгоритмов сжатия и их скорости. Столбцы: скорость сжатия в MB/s, скорость декомпрессии, процент сжатого текста, относительно исходного материала.

Конкретно не даю описаний компьютеров и некоторых параметров, потому что для меня цель больше стояла в удобстве использования этих алгоритмов в продакшене, а удобство и качество кода в некоторых случаях значительно перевешивает скорость. Кроме того, я рассматривал ситуацию использования всего этого дела под .NET, для других платформ результаты могут быть совершенно другие, ибо код пишется разными людьми и имеет разный функционал и возможности.

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

• QuickLZ — проблемы с лицензией,
• LZO — работает через P/Invoke, мутный враппер, какие-то косяки с дебагом, проблемы с 64 битами не ясно дальнейшее развитие, собственно, его высокие показатели в тестах отчасти связаны с ограниченностью функционала, из-за которого, тест оказался в более выгодном положении относительно некоторых других (я даже не уверен, что он стабильно работает, хотя то что работает хотя бы один раз, это точно, я проверил)
• LZF — хорош как вариант микро-компрессора (собственно, весь код можно зафигачить в 200 строчек не сильно экономя, при этом результат вполне сносный. Но, если вы не специалист по алгоритмам, не очень рекомендую заниматься этим делом. Хотя, возможно идея довести код до ума, вполне неплохая (надо записать себе в блокнот "обязательно сделать в следующей жизни").

Также в алгоритме не приняли участие: BZip2, LZMA и PPMd (степень сжатия отличная, скорость настолько низкая, что даже ради научного интереса их тут не стоит использовать.

Некоторые алгоритмы вида классического LZ77, не были найдены под .NET, поэтому тоже их пропускаем.

Теперь детально разберу оставшиеся GZip, LZ4, Snappy.

Gzip

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

Но с выбором реализации есть некоторые проблемы — если вы сравните две верхних таблицы, то увидите что GZipStd (я так обозвал встроенный в .NET) даёт абсолютно разные варианты. Хитрость в том, что до .NET4.5, реализация GZip в .NET была ужасная, и её использовать стоило только в одном случае — никогда. Сейчас всё изменилось, и если вы пишите под 4.5, то вполне стоит использовать этот вариант, если нет критичного требования по скорости.

Если нужна максимальная скорость, то используйте zlibnet, это P/Invoke wrapper, поэтому он работает весьма шустро. Если у вас нет желания использовать P/Invoke (чуть сложнее деплой и требуется больше прав приложению), используйте SharpCompress, он мне показался чуть более удобным, быстрым и функциональным относительно классического SharpZipLib. Есть ещё библиотека SevenZipLib — P/Invoke wrapper к 7zip, но по внешниему интерфейсу я не очень понял, как работать с GZip, хотя в описании указано.

Snappy

Алгоритм от Гугла, ориентированный на максимальную скорость. Для .NET есть 2 реализации P/Invoke с оригинальными названиями: Snappy for .NET и Snappy.Net. Есть Safe-реализация Snappy.Sharp, но я её даже не пробовал, т.к. судя по всему работы ещё дофига, она полузаброшена, ничего особо не протестировано. Опять же, если есть желание — берите сами и дописывайте, иначе не советую использовать (записал второй пункт в блокнот).

Сам алгоритм очень шустрый (судя по всему, разработка велась с учётом особенностей процессоров и их кеширвоания), но сжатие у него так себе. Также у обоих реализаций есть проблемы. Snappy.Net не работает в 32х битах из-за какой-то ошибки в реализации библиотеки, вычисляющей CRC32 (третий пункт в блокнот — написать автору, что он лох и надо поправить). Snappy for .NET — требует VS2010 runtime, о чём надо помнить (я для тестов подложил нужные dll'ки на тестовый компьютер).

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

LZ4

Один из моих фаворитов, благо скорость отличная, но надо выбрать реализацию. Их две и обе хорошие. lz4-net — P/Invoke wrapper и LZ4.NET, флакон от автора с четырьмя разными реализациями, которые выбираются по приоритету и доступности: Mixed Mode, C++/CLI (требуется установленный VS2010 runtime, проверка идёт по наличию пакета в реестре, а не по DLL), Unsafe, Safe. Также, автор, возможно будет пилить дальше и улучшать свой код.

Также у алгоритма есть HC версия, которая даёт лучшее сжатие (но скорость сильно проседает), зато декомпрессия просто безумная. По идее, можно использовать это сжатие для данных, которые редко пишутся, но активно читаются.

Качество сжатия алгоритма зависит от дополнительного буфера на словарь, который в разных реализациях по дефолту 1Мб и 256Кб, в реальности, 64Кб дают пристойный результат, но и 1Мб не очень жалко для объёмных данных. Имейте в виду.

Заключение

Я, пока в раздумьях по поводу алгоритма и реализации, склоняюсь к GZip в P/Invoke исполнении и LZ4 в комплектном. Надо заранее определиться, какая скорость вам требуется: если вы передаёте огромные данные по сети со скоростью 1МБ/c, то GZip'а вам хватит за глаза, а сжатие будет активно помогать уменьшить объёмы. Если же сеть в гигабит, а данных немного, то со сжатием связываться вообще не стоит. LZ4 сидит где-то посередине и при своей скорости подходит для всего мало-мальски сжимаемого.

Решайте сами, я пока думаю, решение напишу позднее, когда потестирую всё это в продакшене (т.е. возможно, спустя длительное время).