Возможна ли ситуация, что такая функция вернет истину?
bool to_do_test(double v) {
map<double,double> m;
m.insert({v,v});
return m.find(v) == m.end();
}
Хочу написать небольшую программу. По сути, большая часть кода — вычисления, которые уже написаны на R.
Сначала хотел не париться и задавать исходные данные в виде таблицы и скармливать это скрипту на R, но решил сделать что-то более законченное с GUI.
Программа должна уметь:
Вычисления несложные, поэтому скорость роли не играет. Хочу параллельно написанию выучить что-нибудь полезное и перспективное из программирования.
Также хочется не заниматься конвертацией кода из R на другие языки, то есть надо, чтобы язык GUI дружил с R.
И ещё, чтобы создание GUI давалось максимально легко, например, путём рисования боксов мышкой.
Подскажите, пожалуйста, на чём писать и какой IDE использовать для этого?
Сперва я хотел бы поздравить всех пользователей ЛОРа с наступающим Новым Годом. Счастливых и весёлых вам выходных в 2019 году!
Осенью из новости на Linux.org.ru я узнал о выходе бета-версии операционной системы Haiku и решил проверить, можно ли использовать её для каких-то своих повседневных нужд обычному рядовому линуксоиду.
( читать дальше... )
Предлагаю (исключительно для галереи) сделать новую фичу.
1. Скриншоты по прежнему попадают сначала в «неподтверждённые».
2. Модераторы МОГУТ (как и прежде) перенести из неподтвержденных в главный раздел галереи.
3. Рядовые пользователи могут голосовать за скриншоты (только в разделе не подтвержденные)
4. взять некоторый срок - например месяц. И некоторое число голосов. Если за месяц набирается некоторое число голосов - то картинка автоматически переходит на главную, без воли модератора.
5. Модератор не может пополнить список «Последние удаленные неподтвержденные» если есть какие-то голоса за картинку и не прошел еще месяц. Если месяц прошел - и голосов не наборолось до некоего числа - может удалить.
6. В особом случае, если не «картинка не интересна», «уже было» и т.п. - а в случаях неккоректного текста, матов, или матов на самой картинке - модератор может удалить картинку, но чтобы это было прозрачно - чтобы было видно что удаленная картинка действительно нарушала правила, а не просто неприглянулась модератору.
Желательно чтобы она была применительно к C++ чтобы быстрее читалась. Хочу систематизировать свои знания в этой сфере. Заранее спасибо.
Есть несколько STL контейнеров, которые в некоторый момент хранят в себе огромное количество мелких объектов съедая большое количество памяти. Потом все данные этих контейнеров освобождаются. Но из-за фрагментации данных в куче стандартный аллокатор не отдает ОС память.
Есть ли какие-нибудь готовые аллокаторы для таких случаев? Или надо писать свой велосипед?
Итак, по просьбе 
ass я выкладываю эскиз слоновьей живописи под рабочим названием Project Tritium вот.
В нём я периодически, в свободное время, пытаюсь сделать нормальную многопрофильность в Trojita
Пока получается хрень)
Теперь к технической части.
Сперва я хотел избавиться от глобальной переменной profileName в которой в другие части программы передается имя профиля. В этом профиле, в свою очередь, хранятся настройки как почтового ящика, так и программы. Попутно хотел отделить настройки программы в глобальный конфиг.
Кхм, для этого вприглядку я тупо создал еще один хидер с настройками AppSettings, куда вынес настройки самого приложения и переменную, которая была предназначена для хранения имени активного профиля activeProfile. По идее, хотел инициализировать строку профиля так.
А теперь первый вопрос: я на самом деле не понял, каким образом строка из объекта настроек QSettings станет доступна в нашей структурке AppSettingsNames ?
Временно для этого члена структуры я захардкодил имя профиля, для проверки. Что привело меня к вопросу №2: Как можно разделить настройки приложения? Если оно их считывает одним махом из объекта настроек.
Резюмируя вышенаписанное, основных вопросов к сообществу 2
Тему лаунчера решил пока отложить — тут интереснее
Из положительного, эта мазня собирается, да :-)
К модератом, пишу в толксы, чтобы помидоры кидали в меня только регистранты.
Найдёте нужным, переносите в Development.
Надеюсь, что коллективный разум наставит меня на путь истинный.
Всем спасибо за внимание!
На канале сообщества CoreHard появились видеозаписи докладов с прошедшей в начале ноября в Минске конференции C++ CoreHard Autumn 2018.
Важный дисклаймер. На конференции были проблемы с Интернетом и он-лайн трансляцией, поэтому в каких-то видеозаписях есть проблемы (например, выпадение отдельных кусочков).
Text Formatting For a Future Range-Based Standard Library - Arno Schödl
Concurrency and Parallelism in C++17 and C++20/23 - Rainer Grimm
Что должен знать каждый C++ программист или Как проводить собеседование - Игорь Садченко и Ко
Информационная безопасность и разработка ПО - Евгений Рыжков
Что не умеет оптимизировать компилятор - Александр Зайцев
Метаклассы: воплощаем мечты в реальность - Сергей Садовников
Asynchronous programming with ranges - Ivan Čukić
Обучаем на Python, применяем на C++ - Павел Филонов
Создание пакетов для открытых библиотек через conan.io - Константин Ивлев
Полезный constexpr - Антон Полухин
Кодогенерация C++ кроссплатформенно. Продолжение - Алексей Ткаченко
Обработка списков на C++ в функциональном стиле - Вадим Винник
Заглядываем под капот «Поясов по C++» - Илья Шишков
Ускорение сборки C++ проектов, способы и последствия - Александр Жоров
C++ CoreHard Autumn 2018. Знай свое «железо»: иерархия памяти - Александр Титов
Actors vs CSP vs Tasks vs ... - Евгений Охотников
Debug C++ Without Running - Anastasia Kazakova
Слайды докладов можно найти здесь
Состоялся релиз SObjectizer-5.5.23 и so_5_extra-1.2.0. Официальный анонс здесь.
Самое главное нововведение — это возможность отсылать сообщения, которые упакованы в специальные объекты-конверты. В конвертах может содержаться дополнительная информация о сообщении. Так же конверт может выполнять дополнительные действия когда сообщение доставляется до получателя (например, может отсылать отправителю подтверждение о доставке).
На базе этой фичи в so_5_extra-1.2.0 реализовано несколько новых инструментов. Так, добавлена возможность отсылки сообщений, которые можно отозвать. Например:
// Отсылаем сообщение и сохраняем ID доставки.
auto id = so_5::extra::revocable_msg::send<my_message>(mbox, ...);
... // Делаем что-то еще.
if(some_condition())
// Решаем, что сообщение нужно отозвать.
id.revoke(); // Если сообщение еще не дошло до получателя,
// то оно будет отозвано и к получателю не попадет.Еще одна из новых фич so_5_extra — возможность ограничить время доставки сообщения. Например, если сообщение не доставлено до получателя за 10 секунд, то оно выбрасывается и получателю уже не доставляется. Выглядит это так:
// Создаем экземпляр сообщения, которое хотим доставить.
so_5::extra::enveloped_msg::make<check_user>(...)
// ...теперь запаковываем его в специальный конверт...
.envelope<so_5::extra::enveloped_msg::time_limited_delivery_t>(10s)
// ...и отсылаем конверт с нашим сообщением..
.send_to(target_mbox);Взять SO-5.5.23 можно на SF.net или на GitHub-зеркале.
Взять so_5_extra-1.2.0 можно на SF.net.
Хочется поблагодарить не только тех людей, которые помогали нам с этим релизом. Но и вообще всех, кто проявлял интерес к SObjectizer-у все эти годы и находил время/возможность делится с нами своим впечатлениями, соображениями и идеями.
PS. SObjectizer-5.5 развивается уже больше четырех лет. И, вероятно, развитие ветки 5.5 подходит к своему логическому завершению. Если кому-то интересно посмотреть на то, что появилось в SO-5.5 за это время, то вот небольшой конспектик.
Есть жирный файл, в нём как-то лежат страницы килобайт по 64. Иногда надо сбросить «грязные» страницы на диск. Нельзя просто так взять и перезаписать страницу in-place: сдохнешь по середине записи и жопа тебе.
Какие вы знаете (видели в разных реализациях всяких там СУБД) способы безопасной записи таких вот страничек в файл?
Я чё-то читал про InnoDB: там в файле есть буферная зона на 128 страничек. Когда системе надо перезаписать несколько страниц, она сначала пишет их в сей буфер, делает fsync(), а потом начинает записывать страницы по своим местам. При поднятии после падения, если в буфере лежат страницы, CRC которых отличаются от CRC тех же страниц, находящихся на своих местах - значит что-то из этого буфера в прошлый раз не дописалось на свои места. Система читает страницы из буфера и дописывает их куда нужно снова. Не очень понимаю как в целом оно устроено...
Короче интересуют вот такие истории в кратком изложении про разные замуты с записью страниц на дисочку.
Читал про какие-то футеры в CouchDB, не понял почти ничего: http://guide.couchdb.org/draft/btree.html#figure/1
Я придумал такой боян:
1. Хотим записать группу страниц на диск.
2. Есть отдельный файл, растягиваемый в конец, на любое число страниц, куда мы сначала пишем все эти страницы тупо последовательно, делаем fsync.
3. В наш write ahead log пишем запись «скинуто в буфер, надо записать в большой файл».
4. Идём пишем в большой файл.
5. После записи всех страничек из буфера в «большой файл», делаем fsync, в журнал пишем «буфер вытряхнут успешно».
Но на VDS хостинге столкнулся с тем, что fsync не гарантирует, что отправленное в write() до него запишется на диск ДО того, что уйдёт во write() после него.
Calendar cal = GregorianCalendar.getInstance();
Date dt; //from somewhere
...
log(dt.getClass().getName()+" / "+cal.getTime().getClass().getName());
log(dt.getTime()+" / "+cal.getTime().getTime());
log("Equals:"+dt.equals(cal.getTime()));
java.sql.Timestamp / java.util.Date
1525107600000 / 1525107600000
Equals:false
Понаделали дат, где как хочу, так и equals. Тупо царское сравнивание по long рулит.
По-моему, в одном из срачей где-то рядом это упоминалось, но не нашёл.
А, собственно, чего сейчас хотят от C++ миддла? Какая обычная вилка зарплат, вопросы на собеседовании и т.д и т.п.
Совсем недавно вышла новая версия свободного графического редактора GIMP. А тут у меня (совершенно случайно) нашлась для него очередная непростая задача. Мне пишут, что, мол, я занимаюсь странными вещами. Например, что кисти размером 512px никто не использует. Или что панорамы в 100 мегапикселей никто не обрабатывает. Что это всё онанизм, если не сказать хуже. Однако, фотографии — вот они, а мне по-прежнему пишут и пишут.
Итак, непростая задача представляет из себя фотографию, снятую на плёночный фотоаппарат аж 1978-го года выпуска. Да, на плёнку, более того — на чёрно-белую плёнку. Конечно, фотографию отсканированную. Разрешение файла — 13269х9058px, что-то около 120 мегапикселей. Совсем недавно кто-то мне писал, что даже FHD (2 мегапикселя) получить на плёнке малореально. Ну, может быть, может быть. Честно говоря, я ожидал, что Гимп с таким снимком надорвётся, и будет работать очень, очень медленно. Я рад сообщить, что я оказался неправ. Расскажу подробнее, это важно:
В недавнем обсуждении меня спросили, использует ли у меня Darktable OpenCL и я был уверен, что да, но в Свойствах конвертера чекбокс «Включить OpenCL» был просто недоступен. А в Гимпе — включён. Оказалось, опенЦЛ в свежей Убунте из коробки не стоит, даже если установлены всякие богомерзкие проприетарные драйвера от Нвидиа. Устанавливается поддержка OpenCL пакетом ocl-icd-dev. После этого и поддержка в DT заработала и Гимп преобразался. Преобразился настолько, что когда я применил на этот самый снимок фильтр Gaussian Blur с радиусом 1024px, Гимп довольно похрюкал и выполнил операцию за семь секунд. 120Мп, 16бит, но, правда, лишь один канал. Но меньше чем 10 секунд. Я потом проверил — преобразовал снимок в RGB и размыл с радиусом 512 — 25 секунд. Это действительно победа для Гимпа, я, признаюсь честно, не ожидал. Для тех кто не понимает, что это вообще и зачем — размытие по гауссу — базовая операция для обработки фотографий, именно на ней основаны всякие увеличения резкости, локального контраста, она нужна для автоматического создания масок и т. д. Короче, это действительно важно и теперь это быстро. Разработчики — просто молодцы.
Я попробовал и некоторые другие операции. Кривые применяются весьма быстро, учитывая немалый размер изображения. Кроп — очень быстро. Преобразование Monochrome-RGB — вполне быстро. Скроллинг, масштабирование — хорошо. Большие кисти всё-таки не очень хорошо, заметные, мешающие лаги. Да, по ощущениям, растровый редактор от Adobe где-то на порядок быстрее. Но не на два, как раньше и это круто. Вот бы ещё ползунки эти жуткие с полями ввода внутри переделали. Правда. Они ужасны и чем лучше всё остальное, тем больше бесят.
Итог: если у вас тормозит Гимп, а OpenCL в настройках включён, возможно, он ни разу не включён. Хотелось бы узнать, как такое могло случиться.
Ещё параллельно открыл сегодняшнюю съёмку в RawTherapee. На снимке, помимо прочего, отпечаток как раз с обрабатываемого кадра; правда, оптический, по старинке. Несмотря на то, что, кажется, DT более прогрессивен, RT мне, на сегодняшний день, нравится больше. Хотя вот тут он ничего хорошего с цветом сделать не смог. Ну да про рав-конвертеры как-нибудь в следующий раз.
Возможно, у кого-то вызовут вопросы пропорции скриншота. Ну вот так, да. Два монитора: 21:9 и 16:9. Лично мне это очень удобно, наконец-то помещается всё что я хочу. Люблю щели!
Привет. Так вышло, что пришлось основательно разобраться в теме и пока память свежа изложил всё в виде небольшой памятки. Удобно по прошествии некоторого времени освежить память прочитав небольшой конспект. Вообще, по-хорошему, блог что ли какой завести )). Просьба - не флудить, ссылки/комментарии/дополнения по теме приветствуются. ЗЫ: подразумевается, что либы -fpic
1. Утилиты readelf, objdump. Читать man elf, man ld.so. N в именах структор
подразумевает 32 или 64.
2. Структура ELF файла:
1. заголовок (смещение 0, struct ElfN_Ehdr). Readelf::ELF Header
2. program header table (массив struct ElfN_Phdr). Содержит информацию о том
как отображать секции в память процесса. Readelf::Program Headers
3. section header table (массив struct ElfN_Shdr). Readelf::Section Headers
3. link_map
3.1. Загруженные в память модули попадают в список (массив) из struct link_map.
Списков может быть много, каждый список - "пространство имён". Для
загрузки модулей в неглобальный список (создание нового) используется
dlmopen().
3.1. Получать link_map модуля через dlinfo() или dladdr1():
[--code--]
#define _GNU_SOURCE
#include <link.h>
#include <dlfcn.h>
#include <stdio.h>
int main()
{
static char addr_in_mod;
Dl_info __info;
struct link_map *lm;
if(dladdr1(&addr_in_mod, &__info, (void*)&lm, RTLD_DL_LINKMAP) != 0) {
printf("link_map:\n");
struct link_map *i = lm;
for(; i->l_prev != NULL; i = i->l_prev);
for (; i != NULL; i = i->l_next)
printf("addr diff=%p name=%s%s",(void*)i->l_addr, i->l_name, i==lm?" <--cur\n":"\n");
}
}
//output:
//link_map:
//addr diff=0x41f000 name= <--current module
//addr diff=0xb7fc4000 name=linux-gate.so.1
//addr diff=0xb7fa3000 name=/lib/libdl.so.2
//addr diff=0xb7dc5000 name=/lib/libc.so.6
//addr diff=0xb7fc6000 name=/lib/ld-linux.so.2
[/--code--]
3.2. Во время переразмещений символ ищется в модулях указанных в link_map
списке начиная от начала списка т.е. порядок важен, "gcc -ls1 -ls2"
libs1.so находится в списке раньше, чем libs2.so.
3.3. При добавлении библиотеки через LD_PRELOAD, она попадает перед остальными
разделяемыми библиотеками в глобальном link_map списке.
3.4. Опция RTLD_DEEPBIND для dlopen - собственные символы модуля приоритетнее
символов из вышестоящих в link_map списке модулей.
Собственные символы загружаемой библиотеки содержат:
1. символы из самой загружаемой библиотеке
2. символы из библиотек, которые были слинкованы с загружаемой из
командной строки (у первых приоритет выше).
3.5. При загрузки через dlopen, библиотеки добавленные с флагом RTLD_GLOBAL
имеют приоритет над RTLD_LOCAL, не смотря на то, что находятся в link_map
списке позже (не относится к получению void f() через dlsym()). Например:
[--code--]
// предоставляет void f(), ссылается на void f().
dlopen("lib1.so", RTLD_LOCAL);
// предоставляет void f().
dlopen("lib2.so", RTLD_GLOBAL);
// при ленивом переразмещении, lib1.so будет ссылаться на lib2.so::f().
[/--code--]
4. RTLD_GLOBAL - символы из загруженного модуля будут участвовать в
переразмещениях для заргуженных в дальнейшем библиотек. RTLD_LOCAL - не будут.
Если lib2.so линкуется с lib1.so через командную строку
"gcc -fpic -shared -l2 s.c -o lib1.so", то видимость символов из lib2.so
наследуется от видимости символов из lib1.so:
[--code--]
dlopen("./lib1.so", RTLD_LAZY|RTLD_GLOBAL); // символы из lib2.so глобальные
dlopen("./lib1.so", RTLD_LAZY|RTLD_LOCAL); // символы из lib2.so локальные
[/--code--]
Если lib2.so подгружается из lib1.so через dlopen(), то видимость символов
из lib2.so контролируется флагом dlopen() при загрузке lib2.so. Способ
загрузки (через командную строку или dlopen) и флаг для dlopen при
загрузки lib1.so значения не имеет.
5. Переразмещение (relocation).
5.1. Переразмещение - процесс соединения символьной ссылки с символьным
определением.
Переразмещение: ленивое - загрузчик вызывается при ссылке на символ, и
ненеленивое - переразмещение при загрузке. Переразмещение переменных всегда
неленивое.
5.2. Символы, требующие переразмещения, содержатся в .rel... секциях. В них
находятся ElfN_Rel структуры.
[--code--]
typedef struct {
Elf32_Addr r_offset; \\ адрес внесения правки (адрес в GOT, например. readelf::Offset).
uint32_t r_info; \\ содержит тип переразмещения и индекс в таблице символов (массив Elf32_Sym[]).
} Elf32_Rel;
typedef struct {
uint32_t st_name; \\ индекс в таблице строк. Т.е. сопостовляет символ с Си строкой.
Elf32_Addr st_value; \\ адрес символа в текущем модуле (readelf::Sym.Value).
uint32_t st_size;
unsigned char st_info;
unsigned char st_other;
uint16_t st_shndx;
} Elf32_Sym;
[/--code--]
5.3. Механизм обращения к переменным (требующим переразмещений):
1. линкер на старте правит .got секцию, она начинает указывать на нужные
данные.
2. ссылка на переменную в коде (в .text секции):
[--code--]
call 44c <__x86.get_pc_thunk.ax> # получаем в eax адрес следующей инструкции
add $0x1bcb,%eax # в eax адрес .got секции
mov 0x14(%eax),%edx # отступ от края .got на адрес переменной,
# разыменовываем в edx
[/--code--]
5.4. Механизм обращения к функциям, для пример - exfn():
1. ссылка на exfn() в коде (в .text секции)
2. переход на "трамплин" в .plt секции - plt@exfn()
3. переход на разыменованный указатель из .got.plt, если переразмещение
уже было произведено, то попадаем на exfn(), иначе:
3.1. возврат в plt@exfn(), в стек кладётся смещение в .rel.plt
секции Elf32_Rel структуры и указатель на link_map список
3.2. вызов ld.so, правится указатель в .got.plt
3.3. переход на exfn().
6. .dynamic секция может быть прочитана из программы через массив _DYNAMIC[],
который содержит struct ElfN_Dyn, автоматически заполняется линкером.
7. Экспортируемые символы из elf модуля указываются в .dynsym секции.
8. -rdynamic опция линкера (для исполняемого ELF) - символы из exe, которые не
были востребованы библиотеками, указанными в командной строке, не
экспортируются (не указываются в .dynsym секции) и не участвуют в
переразмещениях в библиотеках, которые подргружаются через dlopen. Данная
опция заставляет линкер помещать в таблицу все функции.
9. Управление экспортом из модуля
* Управление экспортом по умолчанию:
gcc -fvisibility=default
-fvisibility=hidden
-fvisibility=internal
-fvisibility=protected
* Управление экспортом посимвольно:
__attribute__ ((visibility ("hidden")));
__attribute__ ((visibility ("hidden")))
* Для группы:
#pragma GCC visibility push(hidden)
...
#pragma GCC visibility pop
* static и анонимные namespace
* Управление эспортом через export map, через опцию --version-script
На YouTube стали доступны видео докладов обоих дней C++Russia 2018 (видео первого дня опубликовали в конце июня, на днях добавили еще и видео второго дня).
Вот список в хронологическом порядке публикации видео:
Jon Kalb, C++ Today: The Beast is Back
Алексей Салмин , Memory Management Tips & Tricks
Andrei Alexandrescu, Expect the expected
Евгений Лукьянец, Сборка в Docker с использованием Conan
Viktor Kirilov, Interactive C++ Compilation (REPL): The Lean Way
Mikhail Matrosov, Versatile C++ applied
Илья Шишков, Как научить языку C++: опыт создания курсов на Coursera
Дмитрий Соколов, Кодогенерация как рефлексия для бедных
Herb Sutter, New in C++20: The spaceship operator
Arno Schödl, From Iterators To Ranges
Александр Гранин, Функциональный подход к Software Transactional Memory
Денис Панин, Практическое метапрограммирование: пишем гетерогенную хэш-таблицу
Иван Пономарёв, Crash репорты Android NDK
Фёдор Короткий, Память – идеальная абстракция
Дмитрий Банщиков, Разделяемые библиотеки без внешних зависимостей
Borislav Stanimirov, DynaMix: A New Take on Polymorphism
Vadim Vinnik, Collection Processing. Single essence, multiple manifestations
Victor Ciura, Enough string_view to hang ourselves
Анастасия Казакова, Отладка кода на C++, без запуска и компиляции
Jonathan Boccara, 105 STL Algorithms in Less Than an Hour
Daveed Vandevoorde, Reflective Metaprogramming in C++
Павел Булатов, Переход на WebAssembly: стоит ли игра свеч?
Simon Brand, Modern C++ Parallelism from CPU to GPU
Евгений Зуев, Semantic API for C++ programms
Dietmar Kühl, Concept Based Testing
Дмитрий Кожевников, Подводные камни CMake и где они обитают
Rainer Grimm, Best Practices for Concurrency in Modern C++
Евгений Охотников, Акторы на C++: стоило ли оно того?
Алексей Малов, Опыт применения современного C++ в разработке desktop-приложений
Ivan Čukić, 2020: A void_t odyssey
Андрей Карпов, Эффективный C++ (Маерс тут ни при чём :)
Сергей Шамбир, Когда хорош процедурный C++
Иван Пузыревский, Асинхронность в программировании
Сергей Васильев, Статический анализ: ищем ошибки... и уязвимости?
![GNU Parallel 20180722 ('Crimson Hexagon') [alpha]](https://www.linux.org.ru/images/18106/500px.jpg)
GNU Parallel — это инструмент командной оболочки для выполнения задач параллельно на одном или нескольких компьютерах. Задача может быть одной командой или небольшим скриптом, который должен выполниться для каждой строки ввода. Примеры такого ввода — списки файлов, хостов, пользователей, ссылок или таблиц. Задачей также может быть команда, читающая из пайпа. GNU Parallel может разделять ввод и перенаправлять его выполняющимся параллельно командам.
( читать дальше... )
>>> Источник
Доброго времени суток. Посоветуйте современную библиотеку для разработки TUI на С/C++. Ncurses конечно популярна, но она не протухла? Наличие ады в коде пугает, если честно. Жирные фреймворки типа Qt не интересуют.
void *memset(void *s, int c, size_t n);Почему не char, заполняется все равно одним байтом?
Доброго времени суток! В общем возникла необходимость перенаправить входящий WAN-TCP трафик на IP-адрес другого сервера в интернете... Как это сделать? я в iptables не очень силен.
Задача состоит в том, чтоб клиент с IP-адресом 82.191.xxx.xxx установил сессию с адресом 185.176.xxx.xxx:16555 но пакеты при этом в скрытою перенаправлялись на адрес другого сервера в интернете 46.162.xxx.xxx:16555 а ответ шёл сначала на 185.176.xxx.xxx:16555 а потом уже клиенту 82.191.xxx.xxx
| ← назад | следующие → |