Внешний назначенный ip + порт stun отправляет обратным пакетом в сторону клиента, в последствии на этот же порт отправляются данные от других клиентов. Выглядит это приблизительно так:
1. клиент отправляет пакет стану c целью «пробить дырку» в нате и узнать свой порт + ip
2. стан получает пакет, и отправляет реальный внешний порт + ip обратно.
3. клиент получает свои пробитые порт + ip (реальные) формирует ice кандидата и отправляет кандидата через сигналинг другому пиру
Скажите а есть ли сейчас какой-нибудь способ работать с кодовой базой хромиума или webrtc например? Там gn + ninja.
Я сейчас вручную генерирую здоровенный CMakeLists со всеми хедерами и инклудами и открываю его в clion. Кое как работает, но постоянно надо новые инклуды, исходники, дефайны прописывать. Есть ли другие способы?
http://demo.mpak.su/
Warning: array_key_exists() expects parameter 2 to be array, boolean given in /srv/www/vhosts/mpak.cms/include/mpfunc.php on line 1497
Большие android проекты собираются в разы дольше. :( мои последние 2 проекта собираются(инкрементально — изменение одного java файла) 1м13с и 47с. И еще секунд 7 устанавливаются на девайс. И это на топовом макбуке.
Для андроида существует экспериментальный тулчейн. http://tools.android.com/tech-docs/jackandjill
Что Вы про него думаете? Задумывались ли Вы о возможности какой-либо интеграции с ним?
Время компиляции при работе с андроид проектами всегда была большой проблемой.
Планируются ли какие-нибудь оптимизации в этом направлении?
Да, но как только Вью задестроится, задестроится и анимация, и утечки не будет. Разве нет?
Нет, это не так.
Необходимо понимать как работают Animator и Choreographer. До тех пор, пока анимация не завершится, аниматор будет добавлять колбэк(AnimationHandler) в одну из очередей Choreographer. Этот колбэк исполняется на каждый фрейм и меняет значение пропертей(альфа, смещение и т.д.). Получается бесконечная/долгая анимация будет бесконечно/долго отправдять такие сообщение в очередь на исполнение.
Получается следующая цепочка, которая не дает gc собрать вьюшку(а с ней и контекст):
ThreadLocal(Choreographer) -> у Choreographer жесткая ссылка на очередь колбэков -> у колбэков жесткая ссылка на аниматор -> у аниматора жесткая ссылка на вьюху
В собственных проектах я не стесняюсь делать обновления из-за подобного рода ошибок.
Однако на текущем месте работы не принятно делать пустых обновлений. У нас пустые обновления негативно влияют на рейтинг в маркете. Рейтинг может влиять на выдачу в поиске.
CryptUnprotectMemory в Unicorn.
1. клиент отправляет пакет стану c целью «пробить дырку» в нате и узнать свой порт + ip
2. стан получает пакет, и отправляет реальный внешний порт + ip обратно.
3. клиент получает свои пробитые порт + ip (реальные) формирует ice кандидата и отправляет кандидата через сигналинг другому пиру
Я сейчас вручную генерирую здоровенный CMakeLists со всеми хедерами и инклудами и открываю его в clion. Кое как работает, но постоянно надо новые инклуды, исходники, дефайны прописывать. Есть ли другие способы?
Хотя какая разница. Клиент должен это хэндлить.
А что будет в генерированном классе если вызываемый через рефлекшн метод бросает interrupted exception?
Warning: array_key_exists() expects parameter 2 to be array, boolean given in /srv/www/vhosts/mpak.cms/include/mpfunc.php on line 1497
Что Вы про него думаете? Задумывались ли Вы о возможности какой-либо интеграции с ним?
Планируются ли какие-нибудь оптимизации в этом направлении?
Нет, это не так.
Необходимо понимать как работают Animator и Choreographer. До тех пор, пока анимация не завершится, аниматор будет добавлять колбэк(AnimationHandler) в одну из очередей Choreographer. Этот колбэк исполняется на каждый фрейм и меняет значение пропертей(альфа, смещение и т.д.). Получается бесконечная/долгая анимация будет бесконечно/долго отправдять такие сообщение в очередь на исполнение.
Получается следующая цепочка, которая не дает gc собрать вьюшку(а с ней и контекст):
ThreadLocal(Choreographer) -> у Choreographer жесткая ссылка на очередь колбэков -> у колбэков жесткая ссылка на аниматор -> у аниматора жесткая ссылка на вьюху
Однако на текущем месте работы не принятно делать пустых обновлений. У нас пустые обновления негативно влияют на рейтинг в маркете. Рейтинг может влиять на выдачу в поиске.
А вообще это просто дело привычки: функционал у них практически одинаковый.