Дискорд прокси что это

Обновлено: 07.07.2024

Хочу рассказать про использование мессенджера Discord как основного средства коммуникации в команде. Опыт может быть полезен другим командам, использующим бесплатные мессенджеры, а также всем, кто ищет пути повышения эффективности использования мессенджеров.

Discord – программа странная и выдающаяся одновременно. Почему? Хотя бы потому, что про способы работы в Discord получилась целая статья.




Что-то пошло не так


Давайте сначала разберемся, что не так с «обычными мессенджерами»: Skype, Viber и им подобными.
В данной статье я рассматриваю исключительно мессенджеры, у которых основной функционал доступен бесплатно. Да, существуют прекрасные платные программы, но они за рамками данной статьи, даже если имеют бесплатный урезанный режим.

Обычные мессенджеры устроены так, чтобы работать «из коробки» и без всякого администрирования. Это вполне здравый подход, обеспечивающий низкий порог вхождения: просто создали групповой чат и общаемся в нём. По-другому эти мессенджеры не могут, так как сложные процедуры настройки отпугнут основную аудиторию. Но, как обычно, низкие начальные вложения оборачиваются высокими эксплуатационными издержками. Какие проблемы имеем в итоге.

Разделение по темам. Чем больше пользователей в группе, тем больше количество обсуждаемых тем. Большинство тем интересны ограниченному числу пользователей группы. Подход здорового человека заключается в том, чтобы создавать тематические группы и включать в них только тех, кому тема интересна – такая изоляция уменьшает «информационный шум» от ненужного контента. Но на практике это приводит к полному хаосу. Например, имеем 10 чатов по работе, 4 чата детского сада, 3 чата многоквартирного дома и так далее. И всё это в одном пространстве имён, поэтому мы начинаем путаться в чатах. Они уползают вниз списка, забываются, потом создаются дубликаты забытых чатов, но туда забывают добавить всех пользователей. Если же количество участников примерно от полсотни и выше, то никакие параллельные чаты уже не создаются – слишком сложно поддерживать актуальный список участников. Ведется один супер-чат, содержащий все вопросы жизни, вселенной и всего такого. Результат: большие группы в мессенджерах становятся «токсичными»: контент неинтересен из-за большого количества мусора, мы присутствуем в группах только из-за необходимости.

Discord: начало

Теперь переходим к Discord. Прежде всего заметим, что в Discord есть два режима или, скорее, «вида»: назовем их «обычный» и «сервер». Они существуют параллельно и имеют разные цели. В «обычном» виде Discord – это такой же обычный мессенджер, как и все остальные. Даже с более ограниченными возможностями, чем тот же Skype:

Сервер

Чтобы работать с сервером, надо этот самый сервер иметь. Для определенности будем считать, что мы сотрудники стартапа «Рога и Копыта», поэтому наш сервер будет называться «РК». Создаем сервер путем нажатия на кнопку с большим знаком «+». Сервер – это уютное место, где будет проходить всё наше корпоративное общение (кроме 1-на-1, которое в «обычном» виде, вне сервера). Пользователи должны присоединиться к серверу по приглашению.


В левой панели сразу видим две новые сущности:

  • Текстовые каналы. Это аналог чата, но с некоторыми особенностями и дополнительными функциями. Набор каналов сервера относительно стабилен: каналы всегда остаются на месте, не уползают вниз в истории, как в мессенджерах. Каналы удобны благодаря ролям и упоминаниям, о них далее.
  • Голосовые каналы. В этих каналах мы общаемся голосом. Примерно как радиоприемник: нажимаем на канал (выбираем радиостанцию) и сразу же слышим поток вещания и ещё говорить сами можем. Голосовой канал – это поток, он не имеет начала и конца, нет инициатора звонка и нет самого звонка, который позовёт участников. Подключение к каналу мгновенное. Забудьте про «Я звоню, все ли готовы?» «Добавьте меня в звонок!» «Где ссылка на митинг?». Просто тык в канал — и через пол-секунды вы слышите голоса. Никакого текста в голосовых каналах нет — пишем мы в текстовые каналы. Голосовых каналов нужно столько, сколько голосовых митингов вам нужно вести параллельно. Весьма вероятно, что одного хватит.

Какие роли создавать – решаем сами. Роль соответствует некоему типичному набору действий пользователя. Например, на нашем сервере сделаем такие роли:


  • everyone – техническая роль, означает «все, кто на сервере»; она уже есть и удалить её нельзя.
  • сотрудник – назначаем роль всем сотрудникам, она дает способность видеть в темноте все основные каналы.
  • админ – имеет права администрировать всё остальное. Главнее админов только владелец сервера, который и дает роли админам.
  • кандидат – это не сотрудник, а тот, кого будем собеседовать. Данная роль позволяет придти на наш сервер (по приглашению) и участвовать в удаленном собеседовании: видит он только два канала «собеседование» – текстовый и голосовой.
  • собеседующий – сотрудник, который проводит собеседование. Это не какой-то специальный человек, а просто любой сотрудник с дополнительной ролью. Собеседующий кроме всех своих каналов видит ещё текстовый и голосовой каналы «собеседование». Остальным сотрудникам (тем, кто не хочет участвовать в собеседовании) роль не даем и они не видят эти два лишних (для них) канала.

Каналы

Текстовые каналы на нашем сервере могут быть, например, такие:

  • Каналы «работы» и «детского сада» не перемешаются, так как они будут в пределах разных серверов.
  • Каналы не уползают вниз и не меняют порядка, они на фиксированном месте.
  • Добавление даже большого количества пользователей в созданный канал делается быстро, через права ролей в канале.
  • Нанят новый сотрудник: даем ему нужные роли. Он автоматически попадает в правильные каналы.
  • Увольнение сотрудника: выгоняем с сервера.
  • Создание нового канала: обычно клонируем существующий, если нужны те же права. Настраиваем права ролей – и пользователи автоматически попадают в канал.
Убрать уволившегося сотрудника из всех рабочих чатов в <любом мессенджере>. При этом полного списка чатов нет, а создатель чатов в отпуске.

Упоминания


Можно упомянуть роль:


А вот так можно упомянуть всех, кто есть в канале (любой из этих вариантов работает):



  • Если вы вы не были упомянуты, то нотификация слабая: красный круг в таскбаре и маленькая чёрная пипка в названии канала.
  • Если же вас кто-то упомянул, то нотификация более заметная: красный круг с числом в таскбаре, на иконке сервера и в названии канала; кроме того иконка Discord в таскбаре мигает оранжевым (пока приложение не получит фокус).

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

А минусы какие?

Технические ограничения в Discord.

Стандартные возможности

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

А еще есть.

Боты и возможность написания своих ботов. Но это уже совсем другая тема.

Итого

Discord – это в некотором роде мессенджер 2.0, имеющий средства для эффективного общения больших групп пользователей, в том числе и в корпоративном применении. Создатели программы не побоялись выйти за рамки парадигмы обычных мессенджеров – и получилось неплохо. И в то же время Discord не конкурент обычным мессенджерам, у него своя экологическая ниша. Ведь у простых пользователей, не айтишников и не геймеров, наступает шок и трепет от необходимости администрирования и непохожести на привычные программы.

Надеюсь, информации в статье достаточно, чтобы решить, надо вам это или нет.

UPD1: Комментарий JustDont:
Перед тем как советовать дискорд для контор, нужно обязательно упоминать о том, что вообще-то нужно внимательно честь Discord Privacy Policy, в которой вполне себе английским или русским по белому написано, что Discord собирает всё, что вы ему отправляете. В том числе и всю вашу переписку, обратите внимание. И совершенно не обещает её шифровать и вообще как-то беречь её конфиденциальность от самих себя. И есть ряд сценариев, в которых эта собранная информация вполне может уйти куда-то, куда вам не очень хочется, чтоб она ушла. И нужно оценивать эти риски.



По мере роста Discord сервис Image Proxy начал демонстрировать признаки перенагрузки. Самой большой проблемой стало то, что нагрузка распределялась неравномерно, из-за чего страдала пропускная способность. Запросы выполнялись в совершенно разное время, вплоть до нескольких секунд. Мы могли бы решить эту проблему в существующем Image Proxy, но в то время мы как раз экспериментировали с дополнительным использованием Go, а здесь как будто было отличное место для применения Go.

Переписать сервис, который уже работает, стало нелёгким решением. К счастью, Image Proxy относительно прост и можно было легко сравнить результаты от него и новой альтернативы. Кроме более быстрого выполнения запросов, новый сервис имеет и некоторые новые функции, в том числе возможность извлекать первые кадры видеороликов .mp4 и .webm — следовательно, назовём его Media Proxy.

Мы решили удвоить ставку и собрать собственную библиотеку ресайзинга изображений на Go. Некоторые многообещающие результаты показал один пакет Go на основе OpenCV, но он не поддерживал все нужные нам функции. Мы создали свой ресайзер Go под названием Lilliput с собственным враппером Cgo поверх OpenCV. При создании мы внимательно следили, чтобы не генерировать лишний мусор в Go. Враппер Lilliput делает почти всё, что нам надо, хотя понадобилось слегка форкнуть OpenCV для наших нужд. В частности, мы хотели иметь возможность проверять заголовки, прежде чем принимать решение о декомпрессии изображений: так можно мгновенно отказываться от изменений размера слишком больших изображений.


Первый код не обошёлся без проблем. Изначально Media Proxy выдавал утечку 16 байт на каждый запрос. Это достаточно мало, чтобы сразу заметить, особенно при тестировании на небольшом объёме запросов. Для решения проблемы в Media Proxy были установлены большие статичные пиксельные буфера для целей ресайзинга. Он использует по два таких буфера на CPU, так что на 32-ядерной машине сразу занимает 32 гигабайта памяти. Во время тестирования перезапуск Media Proxy занимал несколько часов, поскольку он использует абсолютно всю память. Это достаточно длительное время, чтобы затруднить выяснение ситуации: то ли у нас действительно утечка памяти, то ли просто превышение лимита во время работы.

В Media Proxy мы столкнулись с ещё одним багом, из-за которого пришлось прерваться. Иногда он выдавал странно испорченные картинки, где одна половина оставалась нормальной, а вторая была «глючной». Мы подозревали, что мы где-то частично кодируем изображение или как-то неправильно вызываем OpenCV. Баг проявлялся нечасто и его было трудно диагностировать.


Реальный глючный JPEG, сгенерированный Media Proxy

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

После исправления этих багов наша уверенность выросла достаточно, чтобы выкатить Media Proxy в продакшн — и мы с радостью убедились, что наши усилия стоили того. Media Proxy требовал на 60% меньше серверных инстансов для обработки такого же количества запросов, что и Image Proxy, выполняя эти запросы в гораздо меньшие разбросы времени. Профилирование показало, что более 90% времени CPU в новом сервисе уходит на декомпрессию, изменение размера и сжатие. Эти библиотеки уже значительно оптимизированы, то есть дополнительного прироста добиться было бы нелегко. Вдобавок, сервис почти не генерировал мусора в процессе работы.

Сейчас Media Proxy выполняет изменение размера изображения с медианным временем 25 мс, а задержка ответа составляет по медиане 85 мс. Он изменяет размер более 150 миллионов картинок каждый день. Media Proxy работает на автомасштабируемой GCE-группе хостов типа n1-standard-16, с пиковым количеством 12 инстансов в обычный день.

После успешной работы сервиса на статичных изображениях мы хотели подключить к нему поддержку изменения размера анимированных GIF, и эту работу OpenCV не сделает за нас. Мы решили добавить в Lilliput ещё один враппер Cgo поверх giflib, чтобы Lilliput смог изменять размер анимированных GIF целиком, а также выдавать первый кадр в формате PNG.

Изменение размера GIF оказалось не таким простым, поскольку стандарт GIF предусматривает использование палитр по 256 цветов в каждом кадре, а модуль изменения размера работает в пространстве RGB. Мы решили сохранять палитру каждого кадра, а не вычислять новые палитры. Чтобы конвертировать RGB обратно в индексы палитры, мы снабдили Lilliput простой таблицей-справочником, которая брала некоторые биты RGB и использовала результат как ключ в таблице индексов палитры. Это работало хорошо и сохраняло оригинальные цвета, хотя такой подход не означает, что Lilliput способен создавать GIF только из исходных файлов этого формата.

Мы также пропатчили giflib, чтобы было легче декодировать только по одному фрейму за раз. Это позволило декодировать фрейм, изменить размер, затем закодировать и сжать его, прежде чем переходить к следующему. Так уменьшается потребление памяти модулем изменения размера GIF. Это несколько усложняет Lilliput, потому что ему нужно сохранять некоторые состояния GIF от кадра к кадру, но более предсказуемое использование памяти в Media Proxy выглядит явным преимуществом.

Враппер giflib в Lilliput исправляет некоторые проблемы, которые были в GIF-ресайзере Image Proxy, поскольку giflib даёт полный контроль над процессом изменения размера. Немалое число пользователей Nitro загружают GIF-анимированные аватары, которые глючат или имеют ошибки прозрачности после изменения размера в Image Proxy, но отлично работают после обработки Media Proxy. В целом, как выяснилось, у программ изменения размера есть проблемы с некоторыми аспектами формата GIF, так что они выдают визуальные глюки для фреймов с прозрачностью или частичных фреймов. Создание собственного враппера позволило решить проблемы, которые нам встречались.

Наконец, в Lilliput добавили Cgo-враппер на libavcodec, так что он смог останавливать видео и получать первый кадр клипов MP4 и WEBM. Эта функциональность позволит Media Proxy генерировать превьюшки для публикуемых пользователями видеофайлов, чтобы остальные люди на основании этой превьюшки принимали решение, запускать видео или нет. Извлечение первого кадра оставалось одним из последних факторов, который останавливал нас от добавления в клиент встроенного видеоплеера для публикуемых файлов и ссылок.



По мере роста Discord сервис Image Proxy начал демонстрировать признаки перенагрузки. Самой большой проблемой стало то, что нагрузка распределялась неравномерно, из-за чего страдала пропускная способность. Запросы выполнялись в совершенно разное время, вплоть до нескольких секунд. Мы могли бы решить эту проблему в существующем Image Proxy, но в то время мы как раз экспериментировали с дополнительным использованием Go, а здесь как будто было отличное место для применения Go.

Переписать сервис, который уже работает, стало нелёгким решением. К счастью, Image Proxy относительно прост и можно было легко сравнить результаты от него и новой альтернативы. Кроме более быстрого выполнения запросов, новый сервис имеет и некоторые новые функции, в том числе возможность извлекать первые кадры видеороликов .mp4 и .webm — следовательно, назовём его Media Proxy.

Мы решили удвоить ставку и собрать собственную библиотеку ресайзинга изображений на Go. Некоторые многообещающие результаты показал один пакет Go на основе OpenCV, но он не поддерживал все нужные нам функции. Мы создали свой ресайзер Go под названием Lilliput с собственным враппером Cgo поверх OpenCV. При создании мы внимательно следили, чтобы не генерировать лишний мусор в Go. Враппер Lilliput делает почти всё, что нам надо, хотя понадобилось слегка форкнуть OpenCV для наших нужд. В частности, мы хотели иметь возможность проверять заголовки, прежде чем принимать решение о декомпрессии изображений: так можно мгновенно отказываться от изменений размера слишком больших изображений.


Первый код не обошёлся без проблем. Изначально Media Proxy выдавал утечку 16 байт на каждый запрос. Это достаточно мало, чтобы сразу заметить, особенно при тестировании на небольшом объёме запросов. Для решения проблемы в Media Proxy были установлены большие статичные пиксельные буфера для целей ресайзинга. Он использует по два таких буфера на CPU, так что на 32-ядерной машине сразу занимает 32 гигабайта памяти. Во время тестирования перезапуск Media Proxy занимал несколько часов, поскольку он использует абсолютно всю память. Это достаточно длительное время, чтобы затруднить выяснение ситуации: то ли у нас действительно утечка памяти, то ли просто превышение лимита во время работы.

В Media Proxy мы столкнулись с ещё одним багом, из-за которого пришлось прерваться. Иногда он выдавал странно испорченные картинки, где одна половина оставалась нормальной, а вторая была «глючной». Мы подозревали, что мы где-то частично кодируем изображение или как-то неправильно вызываем OpenCV. Баг проявлялся нечасто и его было трудно диагностировать.


Реальный глючный JPEG, сгенерированный Media Proxy

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

После исправления этих багов наша уверенность выросла достаточно, чтобы выкатить Media Proxy в продакшн — и мы с радостью убедились, что наши усилия стоили того. Media Proxy требовал на 60% меньше серверных инстансов для обработки такого же количества запросов, что и Image Proxy, выполняя эти запросы в гораздо меньшие разбросы времени. Профилирование показало, что более 90% времени CPU в новом сервисе уходит на декомпрессию, изменение размера и сжатие. Эти библиотеки уже значительно оптимизированы, то есть дополнительного прироста добиться было бы нелегко. Вдобавок, сервис почти не генерировал мусора в процессе работы.

Сейчас Media Proxy выполняет изменение размера изображения с медианным временем 25 мс, а задержка ответа составляет по медиане 85 мс. Он изменяет размер более 150 миллионов картинок каждый день. Media Proxy работает на автомасштабируемой GCE-группе хостов типа n1-standard-16, с пиковым количеством 12 инстансов в обычный день.

После успешной работы сервиса на статичных изображениях мы хотели подключить к нему поддержку изменения размера анимированных GIF, и эту работу OpenCV не сделает за нас. Мы решили добавить в Lilliput ещё один враппер Cgo поверх giflib, чтобы Lilliput смог изменять размер анимированных GIF целиком, а также выдавать первый кадр в формате PNG.

Изменение размера GIF оказалось не таким простым, поскольку стандарт GIF предусматривает использование палитр по 256 цветов в каждом кадре, а модуль изменения размера работает в пространстве RGB. Мы решили сохранять палитру каждого кадра, а не вычислять новые палитры. Чтобы конвертировать RGB обратно в индексы палитры, мы снабдили Lilliput простой таблицей-справочником, которая брала некоторые биты RGB и использовала результат как ключ в таблице индексов палитры. Это работало хорошо и сохраняло оригинальные цвета, хотя такой подход не означает, что Lilliput способен создавать GIF только из исходных файлов этого формата.

Мы также пропатчили giflib, чтобы было легче декодировать только по одному фрейму за раз. Это позволило декодировать фрейм, изменить размер, затем закодировать и сжать его, прежде чем переходить к следующему. Так уменьшается потребление памяти модулем изменения размера GIF. Это несколько усложняет Lilliput, потому что ему нужно сохранять некоторые состояния GIF от кадра к кадру, но более предсказуемое использование памяти в Media Proxy выглядит явным преимуществом.

Враппер giflib в Lilliput исправляет некоторые проблемы, которые были в GIF-ресайзере Image Proxy, поскольку giflib даёт полный контроль над процессом изменения размера. Немалое число пользователей Nitro загружают GIF-анимированные аватары, которые глючат или имеют ошибки прозрачности после изменения размера в Image Proxy, но отлично работают после обработки Media Proxy. В целом, как выяснилось, у программ изменения размера есть проблемы с некоторыми аспектами формата GIF, так что они выдают визуальные глюки для фреймов с прозрачностью или частичных фреймов. Создание собственного враппера позволило решить проблемы, которые нам встречались.

Наконец, в Lilliput добавили Cgo-враппер на libavcodec, так что он смог останавливать видео и получать первый кадр клипов MP4 и WEBM. Эта функциональность позволит Media Proxy генерировать превьюшки для публикуемых пользователями видеофайлов, чтобы остальные люди на основании этой превьюшки принимали решение, запускать видео или нет. Извлечение первого кадра оставалось одним из последних факторов, который останавливал нас от добавления в клиент встроенного видеоплеера для публикуемых файлов и ссылок.


Иногда пользователи мессенджера Discord сталкиваются с проблемой, когда к игровому серверу приложение подключается без остановки. Хоть сама программа и работает, но в Дискорд бесконечное подключение, которое может продолжаться по несколько часов без успеха в конечном результате. Рассмотрим причины возникновения проблемы и способы их решения.

Что делать при бесконечном подключении Дискорд

Самый действенный метод решить вопрос, почему не подключается Дискорд, — это перезапуск программы или компьютера . Обычно после этого работа приложения восстанавливается. Это происходит из-за сбоя в работе ОС. Если этот вариант не помог, переходите к другим решениям.

Проверьте интернет-подключение

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

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

Подключение к сети может пропасть по следующим причинам:

  • баланс нулевой;
  • неполадки с маршрутизатором;
  • технические работы на стороне провайдера.


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

Отключите брандмауэр и антивирусную программу

Бесконечная загрузка, при которой не запускается Дискорд, бывает вызвана работа защитными средствами операционной системы. Отключите антивирус и брандмауэр. Сделать это можно следующим образом:

  1. Перейдите через кнопку «Пуск» в панель управления.
  2. Выберите режим просмотра в виде мелких значков.
  3. В списке средств и инструментов выберите иконка «Брандмауэр защитника Windows».


  1. В левой панели щелкните по пункту включения и отключения.
  2. Поставьте галочку напротив отключение брандмауэра во всех разделах типов сетей.


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

Настройте прокси-сервер

При попытке участников присоединиться к каналу через прокси-серверы зачастую возникают проблемы с подключением в Дискорд, которое становится бесконечным. Чтобы избежать затруднений, следует отключить proxy в настройках ОС. Для этого сделайте следующее:

  1. Запустите окно «Выполнить», нажав на комбинацию клавиш Win + R.


  1. Введите команду «inetcpl.cpl», затем щелкните по кнопке «Ок».
  2. Перейдите во вкладку «Подключения» и нажмите на «Настройка сети» внизу окна.


  1. Если выбрана опция «Использовать прокси-сервер для локальных подключений», то снимите с нее галочку.
  2. Нажмите на кнопку «ОК», чтобы изменения вступили в силу.



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

Если ни один из способов не помог, и в Discord не заходит, то бесконечную загрузку можно убрать, переустановив приложение. Но при этом нужно удалить все остаточные файлы и настройки в папках на жестком диске. Находятся они в папке AppData. Также воспользуйтесь для очистки специальные утилиты, например, Revo Uninstaller.

Читайте также: