Писал я тут на днях web-спайдера на Python, задача, в общем-то, несложная, но нагрузки у нее серьезные, поэтому приходится запускать фактически пять спайдеров (в пяти потоках), кроме того, присутствуют несколько начальных условий, осложняющих дело… В общем, решение было интересным, выдалась возможность хорошенько полазить в потрохах стандартных питоньих либ socket, httplib и urllib2 (если интересно, могу и этот опыт описать).

Сегодня, этим сонным летним утром, я расскажу вам про SSL соединение из PHP скрипта. Расскажу исходя не только лишь из теории, а ещё и решая вполне себе практическую задачу — логин на гугловский блогосервис blogger.com.

Хватит мне уже гнать про теорию, вы мне практику давайте, практику!

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

Споры насчёт того, какой же подход лучше, утихают редко. Сейчас я покажу, как можно скрестить ежа с ужом. У нас есть .NET, которым можно быстро делать и есть Native, который может быстро делать.

В образовательных целях мы будем скрещивать эти два направления. У статьи есть ещё одна цель. В её основе лежит написанная мною и Arwyl'ом программа под названием DuSter. Эта программа представляет собой сервер-пустышку, который позволяет тестировать сетевые программы. Сервер очень прост в использовании, достаточно гибко настраивается, поддерживает файлы описания протоколов, которые позволяют более-менее автоматизировать тестирования работы любых протоколов. Я занимался разработкой сетевого уровня, мой друг — бизнес-логикой и парсингом протоколов. Получилось что-то неимоверно хорошо вылизанное и приятное. Мы гордимся своей программой, и хотим предоставить её сорцы миру, для некоммерческого использования.

Вчера столкнулась с тем, что написанная мною серверная программа (Fedora 10, C), общающаяся с моим же мобильным клиентом (Symbian 9.1, Mobile Python for Series 60) стала давать сбой при пересылке файла.

_____________________________________________________
P.S.: Жаль, что никто не откликнулся советом… Впрочем, уже сама разобралась. Оказывается, стоит контролировать значение, возвращаемое функцией write() — реально может отправляться меньше байт, чем пыталась переслать программа. Пытаясь отправить массив байт, стоит проверять, сколько байт реально отправилось — и упорно досылать неотправленное.
_____________________________________________________

Как то в последнее время я начал активно повышать свои навыки и знакомиться не только и не столько с новыми технологиями. Например, я уже более-менее освоил Java, а именно — занимаюсь сетевыми сервисами. Также начал работать с ActionScript 3, хотя мое мнение относительно применимости в AJAX-приложениях Flash-компонентов не изменилось — их надо использовать там, где они дают максимальное преимущество, а вот вся «обвязка», например, интерфейс пользователя, можно сделать при помощи стандартных технологий. При разработке AJAX-приложений у разработчика есть достаточно большой выбор для решения задачи обмена данными с сервером. В основном, общение с сервером заключается в…

Собственно это скорее полутопик-полувопрос.
Я опишу схему, которая у меня получилась и попрошу у хабралюдей совета — насколько такая реализация имеет право на жизнь и что в ней стоит улучшить =)
Возможно кому то такая идея понравится и он возьмет ее на вооружение — я не против =)

Такая схема у меня используется в двух задачах, однако распишу все на примере одной.
Итак, у меня есть некоторый онлайн браузерный игровой проект. Задача стояла в том чтобы написать максимально быстродействующий чат, обладающий следующими свойствами:
— низкая нагрузка, создаваемая чатом на сервер;
— поддержка большого количества игроков;
— возможность работы как в непрерывном так и в обычном (рефреш) режимах;
— возможность работы у игроков за прокси-серверами.

Абсолютные числа большого смысла не имеют, но как сравнение информация представляет некоторую ценность

Условия

Windows 7 x64 с обновлениями
AMD Athlon X2 4600+ (2.41ГГц)
DDR2 2Гб
.Net Framework 3.5, классы из FCL.
Два 64-битных процесса без дополнительных привилегий.
Антивирус Касперского выключен. С ним результаты сокетов существенно хуже.
Сокеты и именованные каналы в асинхронном режиме.
Размеры буферов подбирались оптимальные, эксперементально для каждого вида IPC.

Введение

Как-то несколько лет назад, на одном из форумов, я нашел такую замечательную фразу — «Каждый уважающий себя программист в жизни должен написать свой чат-клиент». Тогда мои знания не позволяли сделать это. Я просто улыбнулся и прошел мимо этой фразы. Но вот совсем недавно я столкнулся именно с данной проблемой — нужно было написать свой чат. Ну а так как последнее время мой интерес был направлен на изучение и разработку Qt-приложений, на чем будет сделан он, решилось само собой.

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

Начинали мы с разработок под iPhone, где все работало гладко и как положено.
А что работало? Основная задача приложения была послать запрос «Где ты?» — ничего сложного. Но уж очень хотелось бы этот запрос доставлять адресату как можно быстрее, пока он еще актуален. Здесь, имеющий опыт в разработках под iPhone, читатель скажет, что есть APN Service, и будет абсолютно прав. Именно им мы и пользовались, и не знали горя, ибо доставлялись эти уведомления быстрее секунды.

Затем по некоторым внутренним причинам мы перешли на разработки под Android и быстренько все портировали. В частности без каких-либо задних мыслей модуль работы с APN был заменен на аналогичный с C2DM.

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

В ходе исследования этой проблемы я натолкнулся на ряд странных особенностей работы этих уведомлений от Google.

СУБД Caché для взаимодействия через TCP/IP с удалёнными процессами посредством сокетов предоставляет низкоуровневые команды, что может представлять собой сложность для новичков.

А есть ли возможность использовать сокеты «по-другому», не теряя при этом в гибкости, скорости и удобстве разработки?

Мы разрабатываем Flash клиент для клиент-серверного приложения с постоянным сокетным соединением и нам важно защититься от прослушки трафика. Один из способов такой защиты — SSL/TLS шифрование. Во Flash сделать это можно двумя путями — использовать родной SecureSocket или TLSSocket из библиотеки as3crypto. Ниже мы обсудим плюсы и минусы, производительность, а также проблемы с которыми мы столкнулись при внедрении обоих вариантов.

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

Первые 3 теста: каждым из способов выполнялось по 50 запросов подряд к одному сайту.

Корректное отключение

Для корректного завершения сетевого подключения обе стороны должны послать пакеты с сигналом о завершении (FIN), которые указывают что стороны не будут больше отсылать данные, также каждая сторона должна подтвердить (ACK) получение сигнала о завершении сетевого обмена данными. FIN инициируется когда приложение вызывает метод close(), shutdown() или exit(). После завершения работы метода close() ядро переходит в режим ожидания подтверждения от второй стороны приема сигнала о завершении. Это делает возможной ситуацию когда процесс инициировавший отключение будет завершен прежде чем ядро освободит рессурсы связанные с подключением, и снова разрешит использовать порт для связывания с другим процесоом (в этом случае, при попытке использования порта мы получим исключение AddressAlreadyInUse).

Linux (в отличии, к примеру, от FreeBSD) позволяет использовать сырые сокеты не только для отправки, но и для получения данных. В этом месте существуют интересные грабли, на которые я наступил. Теперь спешу показать их тем, кто еще на знает, чтобы каждый, используя свой любимый язык программирования, будь то C++ или Python, мог опробовать их в деле.

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

Raw сокеты предоставляют программисту более широкие возможности по сравнению с остальной частью сокетного API. Все знают об этих «широких» возможностях, но более или менее систематизированное их описание встречается в Интернете нечасто. Попробуем, восполнить данный пробел и разобраться с предназначением raw cокетов и вариантами их применения в сетевом ПО.

Однажды с коллегой столкнулись с проблемой реализации рилтайм мультиплеера на CoronaSDK. Сначала попробовали сервис pubnub.com, но со временем поняли, что не устраивает их latency (у них все через http) и цены. Не найдя ничего получше, решили на скорую руку создать на Node.js свой велосипед (или скорее самокат, потому как весь серверный код умещается в 90 строк с комментариями).

Назвали в шутку NoobHub. Распространяется под лицензией WTFPL.

Здравствуйте, меня зовут Александр Зеленин, я веб разработчик. Сегодня хочу рассказать, как могут работать сайты в условиях нестабильного подключения _{как и обещал}. Проще говоря, что делать если отключили интернет, а деньги зарабатывать надо.

Рассмотрим 3 примера: интернет-магазин, кинотеатр и онлайн-плеер. Для магазина и кинотеатра так же идет разделение на 2 части — что делать на стороне пользователя и на стороне оператора/продавца.

Перевод первой части материала с github, обстоятельно объясняющего работу интернета: что именно происходит, когда пользователь набирает в адресной строке google.com?

Кнопка «ввод» возвращается в исходное положение

Для начала отсчёта выберем момент, когда кнопка «ввод» утоплена. В этот момент замыкается контур, отвечающий за эту кнопку. Небольшой ток проходит по логическим контурам клавиатуры. Они сканируют состояние всех переключателей, гасят паразитные электрические импульсы, и преобразовывают нажатие в код клавиши 13. Контроллер кодирует код для передачи в компьютер. Теперь это почти всегда делается через USB или Bluetooth, а раньше в процессе участвовали PS/2 или ADB.

Давече мне понадобилось реализовать некое подобие собственного statsd-like сервера сбора метрики, но с несколько узко-специфичными фичами, под которые без хорошего напильника не ложилось ни одно готовое или полуготовое решение. В связи в этим было решено реализовать простой клиент-сервер протокол на python с использованием tcp/udp soket'ов. Оговорюсь, что с сетевым программированием знаком я был, да и остаюсь постольку-поскольку, хотя общее понимание tcp/ip стека имелись. Решение в лоб на синтетике показало себя замечательно, но стоило мне нагрузить его более-менее реальными данными (всего-то порядка 20к сообщений в секунду с нескольких потоков) и оно начало показывать свои подводные камушки. Наверное, я просто не смог правильно приготовить raw сокеты, но задачу нужно было решить быстро, времени на глубокое понимание и изучение сетевого программирования не было, поэтому я начал искать решения, где за меня уже хотя бы половину придумали бы. Поиск меня привел к библиотеке ZeroRPC, которая была не так давно, как я понял, выпущенна в мир из недр dotCloud.

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

Началось все с того, что я оптимизировал отдачу ошибки HTTP 408 Request Timeout в сервере приложений Impress, работающем на Node.js. Как известно, у нодовского http.Server есть событие timeout, которое должно вызываться для каждого открытого сокета, если тот не закрылся за указанное время. Хочу уточнить, что не для каждого запроса т.е. не для каждого события request, функция которого имеет два аргумента (req, res), а именно для каждого сокета. Через один сокет может последовательно поступить много запросов в режиме keep-alive. Если мы задаем это событие, через server.setTimeout(2 * 60 * 1000, function(socket) {...}) то должны сами уничтожать сокет socket.destroy(). Но если не установить свой обработчик, то http.Server имеет встроенный, который уничтожит сокет через 2 минуты автоматически. На этом самом таймауте можно отдать ошибку 408 и считать инцидент исчерпанным. Если бы не одно но… С удивлением я обнаружил, что событие timeout вызывается и для тех сокетов, которые подвисли и для уже получивших ответ и для закрытых клиентской стороной, вообще для всех, находящихся в режиме keep-alive. Это странное поведение оказалось достаточно сложным, и я расскажу об этом ниже. Можно было бы вставить одну проверку в событие timeout, но со своим идеализмом я не удержался и полез исправлять баг на уровень глубже. Оказалось, что в http.Server режим keep-alive реализован не то что не по RFC, а откровенно не дописан. Вместо отдельного timeout для соединения и отдельного keep-alive timeout, там все на одном таймауте, который реализован на быстрых псевдо-таймерах (enroll/unenroll), но задан по умолчанию в 2 минуты. Это было бы не так страшно, если бы браузеры хорошо работали с keep-alive и переиспользовали его эффективно или закрывали бы неиспользуемые соединения.