Не для кого не секрет, что «Mail.ru Агент» стал довольно популярным IM проектом. Здесь вам и поддержка ICQ, XMPP, голосовых звонков и даже отправка SMS, только вот компания Mail.ru совсем забыла о разработчиках.
Официальная документация протокола обмена данными Mail.ru Агент описывает версию протокола 1.7 реализованную в 2008 году. На данный момент сервер использует протокол версии 1.24.

Сегодня – очередная лекция нашего курса «Сетевое программирование в UNIX».

В ней Марк Коренберг (Компания Айдеко) рассказывает студентам об «игрушечном» астрологическом протоколе.

Сегодня мы представляем вниманию читателей следующую лекцию курса «Сетевое программирование в UNIX», которую прочитали в Уральском федеральном университете (УрФУ) специалисты SkyDNS и компании «Айдеко». К сожалению, в публикациях произошел вынужденный перерыв. Надеемся, что время ожидания новой лекции вы использовали для реализации сервера и клиента, о которых рассказывали наши специалисты.

Пятая лекция курса «Сетевое программирование в UNIX» от специалистов SkyDNS и компании «Айдеко» уже ждет своих слушателей.

Александр Патраков объясняет, как перевести обычную сетевую программу в программу, основанную на конечном автомате.

О том, что такое конечный автомат, вы узнаете под хабракатом.

Продолжаем осваивать курс «Сетевое программирование в UNIX», подготовленный специалистами SkyDNS и компании «Айдеко». Сегодня мы публикуем шестую лекцию.

В прошлый раз мы рассматривали программы, основанные на использовании конечного автомата. Теперь пойдем дальше и расскажем, как «научить» программу в автоматном стиле обрабатывать несколько одновременных соединений в одном процессе/потоке.

Настало время для седьмой лекции курса «Сетевое программирование в UNIX», подготовленного специалистами SkyDNS и компании «Айдеко». Автор курса Александр Патраков объясняет студентам, как ускорить чтение небольших порций данных из сокета.

Программы, которые были написаны в прошлых лекциях курса «Сетевое программирование в UNIX», обладали бесконечным запасом терпения, то есть беспрекословно ждали, пока не поступят данные для обработки. В новой лекции вы узнаете, как ограничить терпение программы определенными временными рамками.

«Система должна быть спроектирована так,
чтобы оставаться как можно проще
после серии внесенных в нее изменений»
Бьярне Строуструп – программист, автор языка C++

Преамбула

В данной статье мне бы хотелось бы рассказать о довольно популярной, но так редко освещаемой на Хабре библиотеке Portable Components (сокр. POCO). Она будет полезна как разработчикам бизнес-логики программного продукта, так и в решении большинства прикладных задач. При всем изобилии кроссплатформенных библиотек для C++ всё больше людей сталкиваются с POCO лицом к лицу и не знают с чего начать. В данной статье я постараюсь описать технологии, заложенные в библиотеке и дать простейшие примеры решения некоторых задач. Также хотелось бы отметить, что за плечами библиотеки множество успешных как Open Source, так и коммерческих проектов.

Глупо спорить с тем, что аналоговое видеонаблюдение уходит в прошлое: дешевые IP камеры дают картинку сопоставимого качества с дорогими аналоговыми. Помимо этого, IP камеры не ограничены сверху ничем, кроме производительности регистратора, тогда как аналоговые камеры требуют жесткого соответствия приёмной карты, согласования уровней сигнала передатчиков/усилителей/приемников и прочего шаманства.
Конструируя систему на базе IP камер в любой момент можно снять камеру и заменить на более качественную — если при этом сохранить IP адрес и логин-пароль, то, скорее всего, даже не придётся менять настройки приемника — просто в архив пойдёт более качественная картинка.
С другой стороны, это накладывает ограничения на регистратор — он должен быть готов работать с любым разрешением, любым битрейтом, любым кодеком и любым протоколом… Ну или по крайней мере, корректно работать с заявленным.

В мире софта есть два пути — есть linux-way: это набор небольших программ, каждая из которых делает одну функцию, но очень хорошо; и есть windows-way: это огромные кухонные комбайны, которые умеют делать всё, и немного больше. Главная проблема linux-way — это отсутствие интерфейса. Чтобы получить всю пользу придётся скурить маны (или хотя бы прочитать --help), и поэкспериментировать. А так же сообразить, что и с чем можно скомбинировать и как. Главная проблема windows-way — это потеря основной функции. Очень быстро при обрастании доп.функционалом теряются тесты ключевого функционала, и со временем начинаются проблемы даже с ним. А еще при этом начинается инерция мышления: «это главная функция, она оттестирована сильнее всего, там бага быть не может, пользователь делает что-то не то».

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

Так как это моя первая статья здесь, предлагаю начать со знакомства. Кому-то может показаться, что мой ник( First Row) звучит слишком пафосно, поэтому хочу, так сказать, прояснить ситуацию. Я часто подписывался «First row viewer», что означает «зритель в первом ряду». Но при регистрации аккаунта разработчика на Google Play оказалось, что символов слишком много. Пришлось оставить просто «First Row».

Что-ж, мы несколько отклонились от темы, и многим, наверняка, начала порядком надоедать моя болтовня( а внизу-то букв еще много). Поэтому предлагаю перейти непосредственно к нашей теме.

Прежде всего скажу, что здесь мы не будем разбирать IP-маршрутизацию, работу ARP-протокола и теорию самого Spoofing'а (на эту тему я видел пару прекрасных статей на Хабре). Так же предполагается, что вы знаете языки С, Java и имеете хотя бы минимальные навыки разработки под Android. Перейдем сразу к практике, в нашем случае к реализации. Для начала разберемся с инструментами. Лично я пользуюсь Eclipse с плагином ADT и установленным Android NDK (в нашем случае большая часть кода будет писаться как раз в нэйтиве). Возможно, вы будете редактировать сорцы в блокноте и собирать ручками через терминал, или использовать Android Studio, или что нибудь еще. В этом случае, может оказаться, что некоторые мои рекомендации можно будет опустить. В данной статье же я хочу рассказать в том числе о некоторых подводных камнях и граблях, на которые наступил, когда взялся за свой первый проект под Android.

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

Не так давно качество мобильного интернета в моём городе стало постепенно ухудшаться из-за возрастающей на сети операторов нагрузки и некоторые сайты, требующие большое количество соединений (зависимые файлы страницы) стали загружаться ну ОЧЕНЬ медленно. По вечерам скорость опускается на столько, что некоторые сайты могут полностью загружаться в течении нескольких десятков секунд.

Есть несколько способов решения данной проблемы, но я решил выбрать немного необычный для нашего времени способ. Я решил скачивать сайты. Конечно, данных способ не подходит для крупных сайтов, вроде Хабра, тут разумнее использовать парсер, но можно скачать и отдельный хаб, список пользователей, или только свои публикации с помощью HTTrack Website Copier, применив фильтры. Например, чтобы скачать хаб Python с Хабра нужно применить фильтр "+habrahabr.ru/hub/python/*".

Этот способ можно использовать ещё в нескольких целях. Например, чтобы скачать сайт, или его часть, перед тем, как вы окажитесь без интернет-соединения, например, в самолёте. Или для того, чтобы скачать заблокированные на территории РФ сайты, если скачивать их через Tor, что будет очень медленно, или через компьютер в другой стране, где данных сайт не запрещён, а потом передать его на компьютер, находящийся в РФ, что будет гораздо быстрее для многостраничных сайтов. Таким образом мы может скачать, например, xHamster Wikipedia через сервер в Германии или Нидерландах и получить сайт в сжатом виде по SFTP, FTP, HTTP или другому, удобному для вас, протоколу. Если, конечно, места хватит, для такого большого сайта :)

Ну что, начнём!?

В предыдущей статье я рассказал как создать сервер и клиент на Python 3, используя встроенные сокеты. Но у этого приложения было много недостатков, которые я попытаюсь исправить в этой и последующих статьях.

Так какими же недостатками обладает наше приложение?

• Отсылается один единственный пакет, длина которого не может превышать заранее заданной границы в 1 Кбайт.
• Приложение без проверки передаёт аргумент, принятый из сети, в оболочку (URL).
• Недостаток функциональности. Мы не можем, например, скачать все изображения с Хабра, или скачать отдельный хаб.

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

Описание протокола

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

Так как заранее узнать длину сообщения у нас не получиться, придётся передавать её в одном из пакетов. Разумеется, делать это лучше в самом начале первого пакета. Выделив под хранение длины сообщения всего 4 байта, мы сможем передать сообщение длиной свыше 4 млрд символов! Длина сообщения — это информация о нём, то есть, часть заголовка, заголовка нашего протокола. Какого протокола спросите вы? Если верить Википедии, то

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

Мы договорились, что будем передавать данные в нескольких пакетах по TCP, а в начале данных первого пакета будет храниться длина всего сообщения в байтах. Таким образом мы разработали наш простой протокол! Нужно помнить, что наш протокол основан на TCP, а значит, обладает теми же особенностями, что и последний.

Зачем вообще искать IP?

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

• Данные терминалы будут общедоступными и работать в режиме киоска. Поэтому идея добавить на них какую-нибудь панель администрирования, сразу же отпадала, ибо случайный юзер сможет «наклацать» в настройках IP-адреса что ему заблагорассудится.
• Можно было бы зашить в терминалы IP-адрес сервера обновлений, но так как сервер, в моем случае, — это всего лишь десктопное приложение, которое пользователь может запускать на любом компьютере в подсети, то такое решение тоже не подошло.
• Взяв в учет предыдущие два пункта, можно было бы реализовать панель администрирования, со входом по паролю, но, все же, постоянно вбивать новый IP-адрес сервера обновлений — это лишняя головная боль обслуживающему персоналу.

Поэтому от идеи «забирать» я перешел к идее «отправлять» и начал мастерить реализацию автоматического поиска IP-адресов на Python 3.

Примерно год назад вышла моя статья, которую можно назвать "первой частью" данной статьи. В первой части я насколько смог подробно разобрал тернистый путь разработчика-энтузиаста, который мне удалось когда-то самостоятельно пройти от начала и до конца. Результатом этих усилий стала игра жанра RTS "Земля онимодов" созданная мною в домашних условиях без движков, конструкторов и прочих современных средств разработки. Для проекта использовались C++ и Ассемблер, ну, и в качестве основного инструмента моя собственная голова.
В этой статье я постараюсь рассказать о том, как я решил взять на себя роль «реаниматора» и попытаться «воскресить» этот проект. Много внимания будет уделено написанию собственного игрового сервера.

Примерно год назад вышла моя статья, которую можно назвать "первой частью" данной статьи. В первой части я насколько смог подробно разобрал тернистый путь разработчика-энтузиаста, который мне удалось когда-то самостоятельно пройти от начала и до конца. Результатом этих усилий стала игра жанра RTS "Земля онимодов" созданная мною в домашних условиях без движков, конструкторов и прочих современных средств разработки. Для проекта использовались C++ и Ассемблер, ну, и в качестве основного инструмента моя собственная голова.

В этой статье я постараюсь рассказать о том, как я решил взять на себя роль «реаниматора» и попытаться «воскресить» этот проект. Много внимания будет уделено написанию собственного игрового сервера.

Это продолжение статьи, а начало тут.

Примерно год назад вышла моя статья, которую можно назвать "первой частью" данной статьи. В первой части я насколько смог подробно разобрал тернистый путь разработчика-энтузиаста, который мне удалось когда-то самостоятельно пройти от начала и до конца. Результатом этих усилий стала игра жанра RTS "Земля онимодов" созданная мною в домашних условиях без движков, конструкторов и прочих современных средств разработки. Для проекта использовались C++ и Ассемблер, ну, и в качестве основного инструмента моя собственная голова.

В этой статье я постараюсь рассказать о том, как я решил взять на себя роль «реаниматора» и попытаться «воскресить» этот проект. Много внимания будет уделено написанию собственного игрового сервера.

Это окончание статьи, начало тут.

Доводилось ли Вам реализовывать объёмный сетевой обмен посредством TCP- или HTTP-протокола? Насколько, в случае такого опыта, Вы были удовлетворены сопровождаемостью конечного решения? Утвердительный ответ на первый вопрос (пусть даже и без «объёмистости» обмена) и недовольство гибкостью получившейся реализации позволяют рекомендовать эту статью как содержащую один из способов избавления от такого несчастья.

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

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

Чем больше узнаёшь в своей области знания, тем чётче понимаешь, что никто не может знать всего.

По какой-то причине (за что, господи, за что?) моей областью стала разработка игр. Каждый, кто работает в этой сфере, скажет вам: никогда не добавляй сетевой многопользовательский режим в уже готовую игру, никогда, пьяный ты клоун.

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

Проблема №1: ресурсы

Первый вопрос, который у меня возник: как сказать клиенту, что для рендеринга объекта нужно использовать такой-то меш?

Сериализировать весь меш? Не стоит, у клиента он уже есть на диске.

Передавать имя файла? Не-а, малоэффективно и небезопасно.

Ну ладно, может быть, просто строковый идентификатор?

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

При прохождения очередного собеседования мне задали небольшое тестовое задание, написать на Go сетевой сканер открытых портов. Задание в принципе не сложное, но одним из условий было, что в качестве параметра может быть передан как IP-адрес, так и диапазон сетевых адресов в виде сетевой маски: 192.168.8.0/21.

Тема скорее всего очень тривиальная для сетевых инженеров и администраторов и, наверно, даже скучная. Моя цель просто изложить тут алгоритм перевод диапазона IP в сетевую маску (дальше по тексту CIDR) и обратно из CIDR в диапазон адресов.

Всем привет! Сегодня хочу поделиться опытом изучения языка и быстрой реализации высоконагруженного сетевого проекта, использующего так популярные и востребованные сейчас неблокирующие асинхронные сетевые соединения, на новом, красивом, элегантном и очень эффективном языке Rust.
Особый упор в посте сделаю на быстрое и ясное объяснение возможностей языка и платформы специалистам, имеющим большой опыт в веб-разработке, ибо сам таким и являюсь. Существует заблуждение, что кривая вхождения в Rust — очень-очень крутая. Но я покажу, что это далеко не так. Наливаем кофе и погнали!