Если у вас имеется больше одного Linux-компьютера, то вы, вероятно, постоянно пользуетесь ssh. Это — отличный инструмент, но мне всегда казалась в нём странной одна деталь. Несмотря на то, что ssh-соединения позволяют передавать файлы с применением scp и sftp, у нас нет возможности перемещать файлы между локальной и удалённой системой, не запуская программу на локальном хосте, или не подключаясь к локальной машине с удалённой.



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

Я, на самом деле, не вполне достиг этой цели, но подобрался к её достижению очень близко. В этом материале я расскажу вам о скрипте, который позволяет монтировать удалённые директории на локальном компьютере. На локальной машине надо будет установить sshfs, но на удалённой, на которую вы, возможно, не можете устанавливать программы, ничего менять не придётся. Если же потратить на настройку систем некоторое время, и если на клиентском компьютере имеется работающий ssh-сервер, то можно будет ещё и монтировать локальные директории на удалённых системах. При этом не придётся беспокоиться о блокировке IP-адресов или портов. Фактически, если вы способны подключиться к удалённой машине, это означает, что вам удастся и то, о чём я хочу рассказать.

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

Контекст и предыстория

Мне 62. Года три назад решил попробовать написать достаточно сложную систему, до этого было только 20 строк на бэйсике в 1981 г., когда нам на 5 курсе радио-факультета (НГТУ, ранее НЭТИ) воткнули 3 месяца информатики. Профессионалом принято считать того, кто предметом владеет и на нем зарабатывает, так что по факту я — новичок.

С другой стороны, я почти всю жизнь занимался относящимися к музыке алгоритмами, застал процесс развития и железа, и ПО и по мере сил участвовал в нем. В 1978 разработал и собрал синтезатор а-ля Mini-Moog (полагаю, 1-й за Уралом), разработал и выпускал 1-ю в СССР звуковую карту с синтезатором для Агат7(9) — советский аналог Apple II, проектировал модуль FM-синтеза для одного из заводов, сотрудничал с Cakewalk (США), PGMusic (Канада), PowerFX (Швеция) — чаще по схеме: «идеи и воплощение от нас, бюджет — от них», участвовал в международных музыкальных выставках MusikMesse (Германия), NAMM (США) и пр.

A forwarding entity always forwards packets in per-flow order to
zero, one or more of the forwarding entity’s own transmit interfaces
and never forwards a packet to the packet’s own receive interface.
Brian Petersen. Hardware Designed Network

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

А через 10 минут он закажет такси через приложение на телефоне, и ему не придётся даже брать с собой в дорогу наличку.

В аэропорту он купит кофе, расплатившись часами, сделает видеозвонок дочери в Берлин, а потом запустит кинцо онлайн, чтобы скоротать час до посадки.

За это время тысячи MPLS-меток будут навешаны и сняты, миллионы обращений к различным таблицам произойдут, базовые станции сотовых сетей передадут гигабайты данных, миллиарды пакетов больших и малых в виде электронов и фотонов со скоростью света понесутся в ЦОДы по всему миру.

Это ли не электрическая магия?

В своём вояже к QoS, теме обещанной многократно, мы сделаем ещё один съезд. На этот раз обратимся к жизни пакета в оборудовании связи. Вскроем этот синий ящик и распотрошим его.


Кликабельно и увеличабельно.

Сегодня:

1. Коротко о судьбе и пути пакета
2. Плоскости (они же плейны): Forwarding/Data, Control, Management
3. Кто как и зачем обрабатывает трафик
4. Типы чипов: от CPU до ASIC'ов
5. Аппаратная архитектура сетевого устройства
6. Путешествие длиною в жизнь

В этой статье я продолжу знакомить хабрасообщество с техниками, обеспечивающими написание lock-free контейнеров, попутно рекламируя (надеюсь, не слишком навязчиво) свою библиотеку libcds.

Речь пойдет об ещё одной технике безопасного освобождения памяти для lock-free контейнеров — RCU. Эта техника существенно отличается от рассмотренных ранее алгоритмов a la Hazard Pointer.

Read – Copy Update (RCU) – техника синхронизации, предназначенная для «почти read-only», то есть редко изменяемых, структур данных. Типичными примерами такой структуры являются map и set – в них большинство операций является поиском, то есть чтением данных. Считается, что для типичного map'а более 90% вызываемых операций — это поиск по ключу, поэтому важно, чтобы операция поиска была наиболее быстрой; синхронизация поиска в принципе не нужна — читатели при отсутствии писателей могут работать параллельно. RCU обеспечивает наименьшие накладные расходы как раз для read-операций.

Откуда взялось название Read – Copy Update? Первоначально идея была очень проста: есть некоторая редко изменяемая структура данных. Если нам требуется изменить её, то мы делаем её копию и производим изменение — добавление или удаление данных — именно в копии. При этом параллельные читатели работают с первоначальной, не измененной структурой. В некоторый безопасный момент времени, когда нет читателей, мы можем подменить структуру данных на измененную копию. В результате все последующие читатели будут видеть изменения, произведенные писателем.

Удивительно, но об этой подающей большие надежды Time Series DB довольно мало статей на хабре, всего 10, причём она упоминается там вскользь. А ведь версия 0.9 вышла довольно давно, больше месяца назад и была весьма ожидаемой. Итак, что же нового?

Меня давно занимал вопрос: «а что, если попробовать прогнать цифровую запись песни через преобразование Фурье, посмотреть зависимость спектра от времени и попытаться вытащить из полученной информации аккорды песни?». Вот, наконец, нашел время попробовать…

В предыдущей статье мы заглянули внутрь процессора, пусть и гипотетического. Мы выяснили, что для корректного выполнения параллельного кода процессору необходимо подсказывать, до каких пределов ему разрешено проводить свои внутренние оптимизации чтения/записи. Эти подсказки – барьеры памяти. Барьеры памяти позволяют в той или иной мере упорядочить обращения к памяти (точнее, кэшу, — процессор взаимодействует с внешним миром только через кэш). “Тяжесть” такого упорядочения может быть разной, — каждая архитектура может предоставлять целый набор барьеров “на выбор”. Используя те или иные барьеры памяти, мы можем построить разные модели памяти — набор гарантий, которые будут выполняться для наших программ.

В этой статье мы рассмотрим модель памяти C++11.