Кароче, два хоста соединяются используя данные другого хоста (глобальный и локальный (NAT) ip), который находится сервере.

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

Клиент кидает на сервер, пару значений ip и порта. 1. ip самого клиента, откуда отправляется сам запрос (сам хост) 2. глобальный ip (как пример, ip модема).

первый от отправляет в udp пакете, второй получает от из самого запроса (sourse).

База, можно уже и VPN установить на сервер)) больше для аналогий, чем для смысла))

По сути, как раз это и мешает peer-to-peer, два хоста из разных NAT не могут подключится к друг другу, по причине, того, что NAT (модем) защищает внутри себя ip хостов, к которому хочет подключится другой хост. то есть прямого подключение просто нету.

а сам NAT может пропускать, только уже созданные соединения.

so multiplexing creates multiple virtual connections, within a single connection, now within one connection, can work more one application or protocol, it deletes bottleneck, and makes scaleble. other app or protocols think that they the only ones on running on that connetion

when using single stream has several problem 1. can't use several application at once, if app is using stream others have wait

likely multiaddr

each peer has a self-signed certificate, this ceritificate they sing a their private key, which is located on their system

if one packet is lost the next packet cannot will be sent. until first packer is received.

firstly, QUIC uses the UDP, protocol. if a packet is lost, QUIC takes resposablity for it. QUIC repars itself. secondly, quic exposes multiple stream, unlike tcp which exposes a single steam. therefore, at the application layer, there is no need for a multiplexer

a single QUIC packet carring data for one or more streams. QUIC solves HoL blocking, since it works with UPD protocol (allowing packets to be received out of order)

TLS establishs an encrypted and auth connection it runs on top of tcp.

the headers of tcp packets are unencrypted. therefore, when a packet pass throuth other server, server can inspect it, if any field in header has a strange value. server may can reject the packect based of those fieds

по сути, ходьба по лестнице (либо число фибоначи), но отличие в том, что в ходьбе по лестнице мы делали сумму прошлого элемента и позапрошлого. (dp[i-1] + dp[i-2]) а в этой задаче. мы берём либо значение прошолого элемента и всё (di[i - 1]). либо сумма настоящего элемента и позапрошлолго (dp[i] + dp[i-2]).

ну и данной задаче у нас на каждом шагу есть своё число не равное нулю, тогда как в лестнице каждый шаг равен 0 и он считается из прошлых.

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

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

rust использует указатель, чтоб попробовать вызвать метода трейта у структуры, и если если его нету, то rust выдаст ошибку.

по сути. типаж-объект, это тот самый интерфейс. он даёт нам возможность, иметь не с опрелёленным типом. если бы мы использовали Where T: type. что объективности даст мономорфизацию. а с теми типами, которые реализуют в себе этот типаж. по сути, мы начинаем работать с типами не на прямую через тип, а через типаж-объект, что по сути может считатся эквавалентом интерфесов, либо абстракт класса.

this behavior beetween peer, how them will talk to each oher

we created PeerId by publicKey

Wait - просто заставляет поток ждать когда асинхронная операция выполнится, в случае async await поток переходит на другие задачи, а в случае метода Wait() поток другие задачи не выполняет и просто ждёт когда асинхронная операция выполнится.

что можно понять из закономерностей выше это может понизить производительность

OnCompleted - просто ждёт когда асинхронная операция выполнится, и как только выполнится выполнит внутри себя другую операцию, сам он принимает в себе Action

One formate hash and for peer and for key

node have list other nodes, which closer to it. it need to find clode node, for key.

DHT is like a table with data of pc to connect them.

we find distance beetween key1 and peer9. where key1 is data which store in other peer, or this

Дэвид Берковиц 31 июля 1977 года последние жертвы.

так же 1977 пропал весь свет в нью йорке

Есть гланый процесс, он следит за тем, что делают процессы и так же может менять конфигирацию. то есть, как только мы видём команду nginx -s reload. наш главным процесс проверит новую конфигурацию на правильность в синтаксисе, запустит её и создаст новые рабочие процессы, который уже будет обрабатывать новые запросы, по этой конфигураций.

а старые докончат запросы, который остались внутри. то есть запросы, который прям во время reload обрабатываются и потом закончат своё сущестование

Рабочие процессы - это как раз те самые процессы который выполняют обработку запросов (worker_processes)

1064 год корабль выбросила во владения франций на нём был гарольд(потенциально будущий правитель англий). правитель франций, решил выкуп за него получить. но выкупил его вильгельм бастард (конкурнт на трон) и вильгем попросил забыть про трон, гарольд, даже поклялся при святых, что не будет метить на трон но как только он попал в англию он забыл, что поклялся.

1066 король англий умер и королём стал Гарольд. но это фейк.

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

первое, что мы делаем создаём свой интерфейс. через который будут проходить запросы. но вопрос как через виртуальный интерфейс, машину, будет получать данные с другого места этого интерфейса? сам этот интерфейс не может лазить по интернету.

всё просто wireguard создаст по верх одного запроса у которого адресс получателя это ip из вирутального интерфейса. второй запрос, в котором ip будет уже из интернета (допустим ip сервера).

и когда пакет с данными попадёт на сервер, wireguard внешний запрос уберёт, и оставит пакет, в котором ip от виртуального интерфейса.

мы создаём и приватый и публичный ключ. как и с ssh. приватный ключ мы оставляем себе, а публичный отдаём другому устройству.

начало в конце декабря 1968 год : убили подросток на дороге. скорее всего была влюблённая пара.

через пол года в июле 1969 убили еще одну парочку.

и через 3 недели. 1 августа пришло письмо в 3 журнала

в каждом письме было часть шифры, по которому можно было бы узнать имя убийцы. но имени там не было)) но в конце расшифровки была похоже на рандом слов. и в самой расшифровке были ошибки.

так же еще через 3 месяца после прошлого убийства убил еще одну пару.

потом убил таксиста в городе, а не как раньше в лесу.

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

одно из его писем расшифровали только 2020 года.

а есть вероятность, что первое убийство было в 1966.

всегда убивал разным оружием

так и не нашли его кароче, вообще.

и следующий пир(узел), который получил это сообщение делает копию себе и отправляет своим узлам с полным соединением.

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

все это он понимает, так как со всеми имеет служебную связь.

если у узла мало полных соедений, он сам может сделать привику к служебному узлу. и тоже самое наоборот

два узла - могут быть только либо переправлять между собой полные сообщеия, либо только метаданные. но эти узлы могут изменить свой стиль работы. это называется прививка (grafting) - это когда узлы из общение только метадыннаыми переходят в общения с полными сообщениями. и обрезка (pruning)- обратная прививке

Обычно, так идёт связь не все ко всему, ради оптимизаций трафика, чтоб каждый не отправлял всем данные. у каждого пира может быть 3 связи.

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

пока могу сказать, что traint играет роль extensions методов c интерфейсами. мы создаём trait, который играет роль интерфейса, и уже под этот трайт реализуем "extentions" логику, для определённого типа.

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

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

транзакций в redis - тупо, чтоб собрать все операция в очередь и выполнить их по очередно, при этом пофиг выполнится ли все операция, транзацация выполнится даже в любом случае. в postgresql, тразнакция отменится, Если не все операция внутри выполнятся, то есть у некоторых будут ошибки.

суть оптимистической блокировки в том, чтоб не получить одному клиенту не верные данные измененные другим клиентам.

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

по сути

либа для реддиса, StackExchangd.Redis

LRU - чем нужнее, тем меньше шансов на удаления

через api gateway - можно делать, те же запросы к backend. условно он уже отыграет роль proxy. он просто перенаправит (forwarding) на другой url

api gateway - даёт возможность, создавать уже своё api, для взаимодействия со внутреними сервисами yandec cloud

можно просто через это api gateway, создать запрос к другому сервису. apigateWay можно сказать играет роль swagger, он некоторый слой, который помогает именно отправлять запросы куда-то.

по сути - это спецификая, которая помогает создавать единый стиль restApi. по сути спецификая, как и до этого было написано, удобный элемент для того, чтоб программам, работать с api в написаний документаций

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

2.

if let - удобна в том случае, когда нужен только один из всех вариантов, enum. остальные он просто будет игнорировать.

по сути, используя option, мы работатаем с "null" на уровне кода, мы на уровне кода прописывает, может ли этот тип иметь "null" или нет.

всё написано, так, что просто невозможно, использовать пустое значение.

по сути как ассоциативную функцию

Кароче, по сути она работает, компонента,

есть какая-та среда, в которой будет функция, сама среда не знает, ничего про функций, пока не запустить всё.

по сути как было сказано - это как контайнер, со своим миров, в которым мы впихивает свою функцию

а еще можем через ...<nameOldData> создать новую структуру но с новыми данными

можно не писать прописывать всем полям значения, компилятор - это сам сделает на изичиах

можно сказать, что это сервер, где стоит, proxomx

можно сказать, что это qemu в proxmox системе

Умение управлять множество контейренов, через одну точку входа, это и есть оркестрация.

слабая аналогия - это роутер

так то прикольный код, первый раз такое вижу

Превращает элементы коллекция в кортеж, где первый элемент - это индекс этого элемента в массиве, а второй сам этот элемент

а все потому, что по правилу, у данных может быть только один владелец.

s1. не будет сущестовать по примеру ниже.

один байт это 8 бит, то есть 255 возможных значений. сюда как помещятся все эти ackii значения.

в стеке хранится длина и емкость (можно сказать массива) и ссылка на сам массив.

в куче же сами символы (если это строка), ибо он не понятно какого размера, и в будущем может менятся

как только переменная исчезает из зоны видимости она перестаёт существовать.

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

тем самым ссылка будет указавывать хз куда.

сейчас одновременно, и mut ссылка и обычная ссылка, и этого компилятор не разрешает, ибо очень нагло, есть ссылка на неизменяемый объект вдруг изменится, это было бы контр интуитивно

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

по сути ссылка это как есть владелец дома, и те кто в нём прописаны (те кто прописаны это ссылки на дом). по сути те же права, но живой ты или нет, от этого квартира никому другому не уйдёт. квартирой ты можешь пользоваться, но ты ей не владеешь, а только пользуешься

здесь компилятор настолько умный, что сам понимает, что r1 и r2 не будут использованы и тем самым не выдаёт ошибку

Ссылка указывает на указатель

переменные можно закинуть в спецификацию

сам по себе loop, в данном примере это не выражение, а только инструкция

бесконечный цикл

Можно создавать выражение внутри if, и тем самым возвращать значение оттуда и присваивать к переменной

Кароче это функция или любая другая, штука, которая внутри себя имеет вычисления, и возвращает какой-то результат

Можно делать такие массивы: в данном случае будет массив первая отвечает элемент, второй за количество [3,3,3,3,3]

Говорит, о том, как много графики с разной статистикой, много говорит о событиях в реальной жизни.

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

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

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

как удобно

Ваще прикол

бла бла бла