Владимир Дубровин

Такой подход нарушает принцип Кергофса. Взломать ваш алгоритм можно двумя способами:
1. Подобрав алгоритм генерации, это можно сделать, например, перебирая функционалы составляющие функцию вашего алгоритма.
2. В вашем варианте алгоритм к тому же не устойчив к known plaintext атакам. Предположим Алиса передает Бобу сообщение которое известно атакующему - тогда зная это сообщение и проксорив его с "шифрованым" текстом можно получить сгенерированную последовательность и в дальнйшем дешифровать любое сообщение, поэтому в современные алгоритмы обязательно вносится обратная связь и/или какой-нибудь nonce.

P.S. предположу, что вы пытаетесь переизобрести потоковый шифр

Есть два совершенно разных типа FTP прокси - FTP over HTTP и "нативный" FTP прокси,
1. FTP over HTTP раньше использовался исключительно для браузеров, на входе принимал HTTP запрос типа GET ftp://.... и отдавал или оглавление каталога в виде HTML или запрошенный файл, сейчас браузеры FTP не поддерживают и это практически вымерло. Обычно такая функция реализовалась в HTTP-проксях. В 3proxy такая функциональность поддержанва в http proxy (proxy).
2. Нативный FTP прокси - FTP не предусматривает наличие прокси, поэтому такие серверы не стандартны. Обычно с точки зрения клиента работает как FTP сервер, но поддерживает или дополнительную команду OPEN или ищет имя сервера назначения в имени юзера, т.е. чтобы попасть пользователем vasya на сервер example.com вы подключетесь по FTP к прокси-серверу, но в имени юзера пишется vasya@example.com (прелесть в том, что такой прокси можно использовать даже с клиентами не поддерживающими FTP прокси) или перед прочими FTP-командами дается команда CONNECT example.com (для этого клиент должен поддерживать FTP прокси). В 3proxy такая функцииональность поддержана в ftppr.

allow *
parent 1000 http proxy1 port1 login1 password1
proxy -p10001 -i127.0.0.1
flush
allow *
parent 1000 http proxy2 port2 login2 password2
proxy -p10002 -i127.0.0.1
flush
allow *
parent 1000 socks5+ proxy3 port3 login3 password3
proxy -p10003 -i127.0.0.1
...

OpenVPN (по умолчанию), wireguard используют UDP. Можно использовать либо просто VPN с роутингом трафика через него, либо любой VPN-протокол для точка-точка шифрования + SOCKSv5 прокси

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

На прокси сервер обычно передается имя хоста, далее прокси разрешает его в IPv4 и/или IPv6 адрес. При этом возможны разные варианты - прокси может разрешать имена только в IPv4, только в IPv6, сначала в IPv6 а при отсутствии IPv6 адреса у имени в IPv4 или наоборот, или случайно выбирать IPv4/IPv6 адреса из списка доступных адресов.
Проверить можно так как вы и проверяете - обратитесь через прокси к хосту у которого есть и IPv4 и IPv6 адреса и посмотрите с какого адреса (IPv4 или IPv6) пришел прокси. Или просто спросите у поддержки сервиса прокси стратегию разрешения имен.
Если вам строго надо IPv4 или IPv6 вы можете разрешать имя на своей стороне а прокси передавать IPv4 или IPv6 адрес.

в C нет стандартных библиотек работы с графикой, поэтому варианты:
1. Использовать системные функции (например Win32 API или X Window или более высокоуровневые типа KDE)
2. Использовать универсальные интерфейсы, например OpenGL
3. Использовать сторонние библиотеки для работы с графикой, например qt
4. Напрямую работать с оборудованием (в случае если приложение запускается на голом железе, как драйвер ядра или в ОС которая позволяет напрямую адресовать видеопамять)

Ваш вопрос не имеет смысла, классовая адресация окончательно устарела примерно к 2006му году и сейчас не используется, вопрос "Перечислите записи в таблице маршрутизации маршрутизатора 1 для обоих адресных блоков, при этом вам следует использовать как можно меньше записей в соответствии с принципом бесклассовой пересылки." на бесклассовую адресацию, но само задание скорей всего взято из учебника 90х, когда классы еще использовались, поэтому сети упомянуты как относящиеся к классу, фактически это задание на суперсети (такое понятие существовало примерно с 1992 по 1993 год, в 1993м году уже появилась полностью бесклассовая адресация) . Класс не может быть лучше или хуже определенного CIDR, классовая и бесклассовая адресация это два разных подхода к распределению адресного пространства. Сравнитьвать имеет смысл только CIDR и классовую адресацию в целом, CIDR очевидно лучше т.к. дает более гибкий подход к маршрутизации и распределению адресов.

DNS сервер всегда отдает все записи запрошенного типа для данного имени, в тч все MX/SRV записи.

_Клиентом_ выбирается MX с минимальным весом, в случае его недоступности или нефатальной ошибке отправки - с более высоким весом и тд, если у нескольких mx одинаковый вес - порядок между ними выбирается случайно. Поэтому клиенту нужны все MX записи. Примерно так же и с SRV, но там приоритет обеспечивается порядком priority и в рамках одного приоритета выбор между хоставми производится случайно, распределение вероятности задается весом. Т.е. берутся все хосты с минимальным priority и среди них выбирается случайный, но не равновероятно а в соответствии с весом (например если у одного вес 100 а у другого 200 то вероятность выбора второго вдвое выше). Плюс клиент может еще и рассматривать альтернативы между разными сервисами (например между _smtp._tcp и _smtps._tcp) или отдавать предпочтение определенному порту или сети.

На стороне сервера может быть лишь реализован round robin - случайное перемешивание записей, при перемешивании веса и приоритеты не учитываются. round robin требуется стандартом но по факту делается не всеми, например гугловые резолверы (которые 8.8.8.8) его не делают.

Смотрите заголовки Received, как правило в них есть вся цепочка начиная от формирования письма. Можно воспользоваться чем-то типа https://toolbox.googleapps.com/apps/messageheader/ - но обычно все гораздо лучше и больше видно по самим заголовкам. Вот, например, заголовки Received письма полученного через списки рассылки:

Received: from smtp2.osuosl.org ([140.211.166.133]:43816)
	by mx242.i.mail.ru with esmtp (envelope-from <openid-specs-risc-bounces@lists.openid.net>)
	id 1nD7cH-000BCL-Nx; Thu, 27 Jan 2022 19:27:22 +0300
Received: from localhost (localhost [127.0.0.1])
	by smtp2.osuosl.org (Postfix) with ESMTP id 818F640207;
	Thu, 27 Jan 2022 16:27:16 +0000 (UTC)
Received: from smtp2.osuosl.org ([127.0.0.1])
	by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 0oLF9wJ5GV1X; Thu, 27 Jan 2022 16:27:15 +0000 (UTC)
Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34])
	by smtp2.osuosl.org (Postfix) with ESMTP id F27D4401DD;
	Thu, 27 Jan 2022 16:27:14 +0000 (UTC)
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by ash.osuosl.org (Postfix) with ESMTP id 4A7A21BF84C
 for <openid-specs-risc@lists.openid.net>; Thu, 27 Jan 2022 16:27:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 36EB3401DD
 for <openid-specs-risc@lists.openid.net>; Thu, 27 Jan 2022 16:27:11 +0000 (UTC)
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 6ALaTL5qxGLX for <openid-specs-risc@lists.openid.net>;
 Thu, 27 Jan 2022 16:27:09 +0000 (UTC)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77])
 by smtp2.osuosl.org (Postfix) with ESMTPS id B051F400CC
 for <Openid-specs-risc@lists.openid.net>; Thu, 27 Jan 2022 16:27:09 +0000 (UTC)
Received: from rcdn-core-7.cisco.com ([173.37.93.143])
 by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA;
 27 Jan 2022 16:19:37 +0000
Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19])
 by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 20RGJaJO009169
 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK)
 for <Openid-specs-risc@lists.openid.net>; Thu, 27 Jan 2022 16:19:36 GMT
Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xbe-rcd-004.cisco.com
 (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 27 Jan
 2022 10:19:36 -0600
Received: from xfe-aln-005.cisco.com (173.37.135.125) by xfe-rtp-001.cisco.com
 (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 27 Jan
 2022 11:19:36 -0500
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57)
 by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14
 via Frontend Transport; Thu, 27 Jan 2022 10:19:35 -0600
Received: from BL0PR11MB3267.namprd11.prod.outlook.com (2603:10b6:208:6b::22)
 by BL1PR11MB5318.namprd11.prod.outlook.com (2603:10b6:208:312::24)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.17; Thu, 27 Jan
 2022 16:19:35 +0000
Received: from BL0PR11MB3267.namprd11.prod.outlook.com
 ([fe80::c981:5c34:715b:b3a6]) by BL0PR11MB3267.namprd11.prod.outlook.com
 ([fe80::c981:5c34:715b:b3a6%3]) with mapi id 15.20.4930.018; Thu, 27 Jan 2022
 16:19:34 +0000