P2p0 android что это

История создания библиотеки для группового общения андроид-устройств через Wi-Fi Peer-to-Peer соединение

Предыстория

Мотивом написания данного приложения послужила курсовая работа по дисциплине «Компьютерные системы и сети». Честно говоря, эта одна из самых мной нелюбимых сторон в компьютерных технологиях, и я решил «подстраивать» курсовой проект под свои интересы, а именно, под Андроид-разработку.

Было решено создать библиотеку для соединения Андроид-устройств по средством Wi-Fi Direct технологии и передачи данных между ними (Wi-Fi Peer-to-Peer соединение осуществляется как раз с помощью технологии Wi-Fi Direct).

Почему Wi-Fi Direct?

После одобрения идеи о локальном соединении устройств передо мной встал вопрос: С помощью какой технологии собираюсь я это осуществить? Рассматривались следующие варианты:

• Bluetooth
• Wi-Fi Hotspot
• Wi-Fi Direct или Wi-Fi Peer-to-Peer

Bluetooth

Wi-Fi Hotspot

Создание точки доступа является не плохим вариантом, однако меня смущает ситуация с потерей основного Wi-Fi соединения. Я бы хотел, чтобы пользователи могли находится в локальной сети, и одновременно иметь доступ к глобальной, например быть подключенными к своему домашнему роутеру.

Однако с помощью Wi-Fi Hotspot можно добиться максимальной скорости передачи данных (приложения Portal, SHAREit).

Wi-Fi Direct или Wi-Fi Peer-to-Peer

Данный подход решает все вышеупомянутые проблемы:

1. неограниченное кол-во клиентов (если не так, прошу меня поправить)
2. большой радиус действия
3. соединение с устройствами по средством Wi-Fi без создания точки доступа
4. технология поддерживается с API 14 (Android 4.0)

Но сразу закрадывается сомнение, мол Wi-Fi Peer-to-Peer, тогда как мы собираемся создать группу с владельцем и клентами, и тем более, чтобы все друг с другом общались. Это как раз-таки и является основной причиной написания данной статьи.

Wi-Fi Aware

Начнем с проблем

Скажу честно, предоставляемая документация by developer.android.com давалась мне нелегко. И я начал искать сэмплы. Перебрав кучу материала, наткнулся на наиболее интересный sample by Google.

Никогда не думал, что на официальном сайте от Google можно найти говнокод, но это как раз тот случай. Однако даже этому стоит отдать должное, так как благодаря данному ресурсу я реализовал то, что хотел.

В сэмпле продемонстрирован пример чата двух устройств, которые нашли друг друга в списке, отображающем рядом находящиеся Wi-Fi Direct устройства с запущенным приложением чата. При выборе партнера непосредственно открывается ChatActivity.

Очень важным моментом является поиск собеседников: в списке не будут отображаться такие Wi-Fi Direct устройства, как телевизор или какая-нибудь гарнитура. Отображаются только устройства с запущенным Chat-приложением.

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

Что было реализовано для демонстрации работоспособности библиотеки

Приложение представляет следующий функционал:

1. выбор роли в процессе работы с приложением (для примера были созданы «Мафия» и «Мирный житель»)
2. создание группы
3. присоединение к существующей группе
4. общение между устройствами (при нажатии на кнопку меняется ее цвет как у инициатора, так и у всех остальных, соответствующих текущей роли (либо broadcast))

Описание экранов слева-направо:

• стартовый экран с выбором действия и роли
• список присоединившихся устройств к текущему владельцу группы
• список активных групп, к которым можно присоединиться
• сеттинги приложения (логин устройства, название группы, пароль для вхождения в группу)
• «игровой» экран

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

Основная концепция работы библиотеки

Логика построена на основе архитектуры клиент-сервер. Сервером является владелец группы, клиентами — подсоединившиеся пользователи.

В приложении присутствуют собственные Serializer/Deserializer для преобразования передаваемых данных в массив байтов и обратно. В передаваемых данных хранится следующая информация:

• кому отправить (мафии, мирным жителям, всем)
• какого рода данные (например: изменение цвета кнопки)
• сами данные (сериализованный Object)

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

Компоненты библиотеки

Самая сложная проблема во время разработки

Когда проект дошел до стадии тестирования мультиплеера (> 2 устройств), тут-то и началась жара. Два устройства как и прежде у меня соединялись без проблем (для чего впрочем и создан Wi-Fi Peer-to-Peer), однако при подсоединении третьего звена почти всегда происходил треш. При нажатии на кнопку у «владельца» (позже поймете, почему в кавычках) цвет менялся только у того клиента, с которым «владелец» последний раз общался.

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

До этого я считал, что тот девайс, который подсоединяется к другому, всегда будет клиентом… а это далеко не так. При соединении устройств рандомно передавались права владельца одному из них, что и побудило меня на поиск настройки config’a, который бы исправил эту ситуацию, и сделал подсоединяемое устройство клиентом.

При соединении двух устройств прописывается специальный config, который в себе содержит:

• адрес устройства, к которому мы хотим присоединиться
• wps.setup позволяет установить, как мы будем соединяться: с паролем или просто по нажатию кнопки
• groupOwnerIntent — вот он (споймал!), тот, кто решил мою проблему; целочисленное поле, значение которого варьируется от 0 до 15 (0 — хотим быть клиентом, 15 — хотим быть владельцем); по умолчанию -1, что дает системе право самой выбрать роль в этой связи

Status’ом (enum) выше является текущее положение устройства, если он создатель группы — GroupOwner, иначе — Client.

Необходимые доработки

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

Защита. Для входа в определенную группу было бы неплохо реализовать авторизацию.

Заключение

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

Это моя первая статья, поэтому судить строго. Спасибо за внимание.

→ Ссылка на GitHub
(модуль wifidirect может быть без проблем перенесен в любой андроид-проект)

Источник

Android P2P (прямое подключение) через Интернет (за NAT)

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

Одна проблема, которую я пытаюсь решить, прежде чем погрузиться в кодирование, – это проблема связи между несколькими игроками. В настоящее время существует возможность использования центрального HTTP-сервера в качестве центрального концентратора для связи (в сочетании с Android C2DM API, позволяющим передавать сообщения с HTTP-сервера на устройства). Это кажется хорошим решением, потому что теоретически, если у вас есть доступ к Интернету, он должен работать отлично, независимо от того, находитесь вы за NAT или нет.

Однако предлагаемое решение имеет недостаток существующей одной точки отказа / дополнительной нагрузки (веб-сервера). Поэтому я хотел бы попробовать другие варианты. Я думал о прямых подключениях с использованием Sockets между клиентами (с тем, что веб-сервер используется только как начальная точка встречи), однако это будет работать только в том случае, если все устройства находятся в одной сети. Учитывая, что сегодня мы почти всегда находимся за NAT маршрутизатора, как я могу достичь прямой связи? Я читал о перфорации дыр, но я не могу найти хорошую библиотеку, которая хорошо документирована (содержит хорошие примеры использования) и работает на Android точно. Кроме того, большинство (если не все) методов перфорации отверстий (STUN, ICE и т. Д.) Широко доступны только для работы с UDP, что отлично подходит для аудио / видео и многопользовательских игр в режиме реального времени, которые могут потерять некоторые сообщения, но для многопользовательского режима На основе игры важно гарантировать доставку данных каждого хода (что невозможно напрямую с UDP).

Итак, любые идеи о том, как добиться надежной перфорации отверстий (предпочтительно по TCP) между устройствами Android за NAT? Он не должен работать в 100% случаев (некоторые незнакомые NAT могут не поддерживаться), но было бы неплохо, если бы он работал в большинстве случаев.

Используйте xmpp через smack over gtalk. Вам не нужно беспокоиться о сервере и о единственной точке отказа. Позвольте google беспокоиться об этом! Я написал Тетрис, чтобы он играл против двух игроков, использующих gtalk в качестве уровня общения. http://code.google.com/p/tetrads-drop-lite/ Вы можете попробовать MUC, если хотите больше игроков.

Вы в значительной степени вынуждены использовать посредника. Вы можете найти Natblaster для механизма, который будет работать для установления TCP-соединений между некоторыми NAT-устройствами, но это не то, что вы можете использовать в Android, не укореняя оба устройства. И даже тогда, это экспериментально.

Лучше всего, вероятно, использовать существующую федеративную систему обмена сообщениями, такую ​​как jabber.

UDP не является надежной доставкой, но вы можете сделать его надежным, требуя, чтобы отправить пакеты UDP, чтобы подтверждения были возвращены. Это, наряду с несколькими другими требованиями, является тем, что делает TCP надежным по IP (что на самом деле ненадежно).

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

Источник

Различные способы попасть в i2p на андроид устройствах

Способ 1. Шлюзы

Данный способ очень прост, но есть подлянки. Например чтобы попасть на сайт *.i2p надо просто подписать .in/.us/.to т.е. в адресной строке запрос будет выглядеть вот так: *.i2p.us. Но к сожалению многие шлюзы выходят из строя либо не могут связаться иногда с сайтом.

Способ 2. Приложение от разработчиков i2p.

Способ чуть гиморнее связи с нестабильностью на текущий момент. Скачать его можно тут zzz.i2p/forums/17 либо через шлюз zzz.i2p.us/forums/17, а также в моем топике на 4pda 4pda.ru/forum/index.php?showtopic=369746. Инструкцию копипастить с 4pda не буду ибо нет смысла, но предупреждение обязан написать (Просьба разработчиков) «Внимание приложение еще не стабильно, могут быть серьезные проблемы с анонимностью. Разработчики рекомендуют использовать ПК версию в большинстве случаев.»

Способ 3. Свое прокси i2p

Самый гиморный, но зато самый эфективный способ. Нам нужен белый статичный ip (если нет пользуемся сервисом no-ip) Если у вас есть личный домен 1-ого уровня можно прикрепить его к нашему ip либо если используем no-ip сделать переадресацию через CNAME, затем нам нужна программа ccproxy (т.к. думаю большинство используют винду, а не линукс). Если у вас WiFi роутер и вы находитесь за NAT, то сделайте переброску порта например 333 на ваш компьютер(в каждом роутере по своему).
Запускаем программу CCproxy и в настройках прописываем в первых 4 строчках порт 333, затем нажимаем кнопку другие и открываем вкладку cascading где в поле адрес пишем 127.0.0.1, а в порт 4444 (Не забываем, что у вас должен быть настроен и активен i2p на компьютере), сохраняем и идем во вкладку прочее (последняя) там мы можем задать пароль админа и сменить язык (есть русский надеюсь вы поняли из предыдущих моих фраз). затем сохраняем все и выходим из настроек в основное окно программы тут мы нажимаем аккаунт и настраиваем пользователей которые могут использовать прокси (если вы хотите сделать прокси общедоступной, то ничего можете не делать, главное чтобы в допуске было указано все).

Ну вот и все теперь во всех браузерах которые имеют настройки прокси можно прописать ваш ip/домен, порт 333 а также логин и пароль если есть (в большинстве браузеров логина и пароля нет, но при подключении к прокси вылезет окно где их можно ввести).

Источник

Связь P2P в реальном времени между мобильными устройствами

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

Есть ли способ общаться с помощью XMPP между мобильными устройствами без сервера (или с помощью мобильных устройств в качестве серверов)?

Является ли Sockets хорошей идеей? Т.е. иметь серверный сокет и клиентский сокет и обмениваться информацией таким образом.

Есть ли более разумный способ? Я слышал о jWebSocket, но я действительно не знаю, как это работает, или если оно того стоит.

РЕДАКТИРОВАТЬ

Процесс выглядит следующим образом:

1. Я использую Parse в качестве сервера / backend http://parse.com
2. Когда пользователь запускает приложение, список пользователей извлекается с сервера анализа
3. Затем пользователь имеет (может иметь) ip других клиентов, а затем пытается связаться с ними.

Проблемы
1. Parse не поддерживает сервер XMPP или другие типы серверов

Так вот что я, наконец, закончил:

Архитектура выглядит следующим образом

• Каждый телефон имеет SocketServer, слушая соединение
• На каждом телефоне есть BroadCastReceiver, который слушает изменение соединения с данными (если соединение потеряно или создано).
• Каждый телефон может создавать сокеты для связи с другими телефонами
• Сервер, на котором отображаются идентификаторыклиентов и клиент-ips

Теперь основной поток выглядит следующим образом

1. Когда клиент (телефон) подключается к Интернету, BroadcastReceiver замечает это изменение и отправляет на сервер сообщение с его идентификатором и IP-адресом
2. Сервер получает это, и как ответ возвращает идентификаторы списка (идентификаторы других зарегистрированных пользователей).

Соединение выполнено vía java Sockets, я построил простой протокол для отправки параметров, подобных синтаксису http, сообщение имеет следующую форму:

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

Когда клиент отправляет сообщение, он должен указать идентификатор отправителя. Затем он запрашивает сервер для идентификатора, а затем сервер отвечает с помощью ip (этот ip затем кэшируется в клиенте с простым сопоставлением ).

Сообщение принимается сервером, который затем уведомляет об этом MessageReceivedListener s

Преимущество этого заключается в следующем:

• Нет необходимости в сложном сервере: разработчики мобильных приложений (например, я) обычно не хотят тратить много времени на стороне сервера.
• Телефоны обычно подключаются и отключаются от мобильных сетей очень часто, поэтому обычно требуется механизм для восстановления соединения (в этом случае BroadcastReceiver является тем, кто уведомляет сервер о том, что его IP-адрес был изменен, а другие телефоны просто запрашивают сервер) ,
• Это простой протокол, поэтому синтаксический анализ выполняется довольно быстро, но при необходимости сложные объекты могут быть отправлены через GSon
• Это отделяет проблемы: приложение никогда не знает IP других телефонов, просто их идентификаторы, которые в моем случае являются фактическими идентификаторами пользователей Facebook.
• « MethoName », о котором я упоминал ранее в синтаксисе протокола, заставляет MessageReceivedListener подписываться только на одно «имя метода », поэтому они получают только сообщения, относящиеся к ним.

Любые предложения и критики приветствуются

Вы можете посмотреть на использование библиотеки клиентов IRC, например http://jerklib.wikia.com/wiki/JerkLib_Wiki . Таким образом, вы можете использовать открытый IRC-сервер для связи с другими устройствами …

Я не использовал его, но я сделал закладку для дальнейшего чтения, потому что я думал, что это новая концепция …

Источник