ICANN: Свободны всего 8-9% IP-адресов

> Так что можно давать стразу каждому клиенту по 255

можно и больше...

...ведь 2^(80 - = 2^(72) = 4722366482869645213696 # это помоему очень очень очень даже многовато клиентов

так-что можно одному провайдерскому клиенту давать и 2^32 адреса (без ущерба для всех).
в этом случае число таких клиентов у одного провайдера составит: 2^(80 - 32) = 2^(48) = 281474976710656 # что тоже очень даже не мало!!

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

они ведь опять захотят сделать аудентификацию по тупому PPPoE (вместо того чтобы сделать эмуляцию прозрачного Ethernet+DHCP, но и с передачей меток-портов программируемых_свичей)

Ага, теперь каждый холодильник/микроволовка/кофеварка под ВинМобайл сможет слать спам и ДОСить Перспектива просто неймоверно радужная )

а его (ipv4) как раз планируют поддерживать до 2020 года

ничего не придётся менять.

провайдеры будут обеспечивать динамическую трансляцию ipv6-DNS-доменов (результаты AAAA-типа) в ipv4-DNS-домены (результаты A-типа. с динамическим временным ipv4-адрессом)

эти протоколы сейчас тестируются и проверяются...

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

----------

другое дело что самому тебе (через 3 года) не захочется использовать свой домашний маршрутизатор который у тебя сейчас

(а ежеле ты говоришь про маршрутизаторы провайдера -- то разумеется их как минимум раз в 10-лет нада менять)

вот спасибо! а потом благодаря таким умникам приходится выпрашивать у прова белый ip или ждать часами чтобы что-то скачать с рапиды

Больше покачать неоткуда, как с этой помойки? Фалообменники мастдай - со своим платным доступом. И без них неплохо живётся, без порнухи и срыва докачек на 95%.

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

> 95% процентам пользователей реальные ip не нужны.

большенство пользователей думают что "Internet" и "Web" это одно и тоже..
и чтоже теперь изза этих недоучек -- превратим интененет в кучу кривых NAT??!

..."уникумы" которые щитают что белые-ip не нужны -- можете мне рассказить:
какого фига провайдерский NAT разеденяет TCP-сессии которые являются неактивными чуть мнее чем два часа?

(ведь два часа неактивности TCP это ещё не обозначает потеря соеденения)

если неумете настраивать NAT -- то предоставляйте былые ip! потомучто я (как клиент) сам лучше знаю какие TCP мне разъеденять нада а какие не нада :-/

....и не нада говорить всякую лабуду по типу что программы должны посылать Keep-Alive пакеты кадые 2 минуты. ничиего они не должны! TCP не должен сам по себе разъеденяться (это заложено в его RFC) !

Все предельно просто: дроп сессии через 2 часа неактивности, это обычная защита от утечки ресурсов
Я не знаю ни единого нормального сервиса который бы не слал кипэлайвы или же мог сохранять неактивность 2(!) часа...

20115 Наверно просто сам быдло кодер который забыл про Keep-Alive а теперь пытается спихнуть свою неграмотность на провайдера.

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

..а всё потомучто TCP сам по себе КОГДА ЭТО ТРЕБУЕТСЯ ПО RFC -- щлёт SYN-пакеты которые говорят о том что "всё нормально связь не потеряна!"

прочти матчасть блин!

# p.s.: еслибы канал был UDP -- то это другое дело

Гость: quest> 20115 Наверно просто сам быдло кодер который забыл про Keep-Alive...

Гость: 20115> я не забыл -- я его спецом отключаю...

а весь прикол в этом и состоит -- что пока я пользуюсь ПРОВАЙДЕРСКИМ nat -- то провайдер мне диктует: "чихать я(провайдер) хотел на RFC! приказываю делать тебе Keep-Alive"

..а когда провайдер предоставляет белые-ip -- то TCP работает так как он и должен работать, причём независимо от того что говорят "умники" вроде {Гость: quest} ... пусть хоть слюной изойдёться от уверений в необходимости Keep-Alive -- сёравно он не не нужен , и никакие TCP нискем не обрываются!

[QUOTE]а всё потомучто TCP сам по себе КОГДА ЭТО ТРЕБУЕТСЯ ПО RFC -- щлёт SYN-пакеты которые говорят о том что "всё нормально связь не потеряна!"[QUOTE]
Бог мой... Что за феерический бред!
SYN пакеты никакой TCP не шлет, идиoтинa!
Вот когда приложение кип-алайф запросит - тогда пойдут и сины, и аска! Кури РФЦ, тупицa!

> Вот когда приложение кип-алайф запросит - тогда пойдут и сины, и аска! Кури РФЦ, тупицa!

ты сам идиот!

может объяснишь что делают параметры сетевой подсистемы:


???

если не можешь объяснить -- то я сам отвечу -- это настройка которая показывает сколько нужно ждать времени чтобы TCP-канал посылал SYN-пакеты подтверждающщие что "TCP всё ещё жив, даже если ничего не посылает"

критины... нифига не шарят...

приделай следущий эксперимент:

1. возьми два компа
2. подключи их по TCP (напиши для этого маленькое приложение) , но чтобы без команды эти приложения ничего не посылали внутри TCP-канала (и не запрашивали никаких keep-Alive).
3. продержи эти компы (и программу) включенными в течении суток
4. убедись что TCP-канал не разорвался сам, и что он работает. хотя полезные данные не передавались аж целые сутки!
5. <подумай почему так произошло>

далаее сделай тот же самый эксперимент...
....но только после пункта [3] один из компов выведи из строя (но таким образом чтобы он не успел послать сигнал второму компу о том что он завершает свои сетевые соеденения . например вытыкни Ethernet, затем перезагрузи комп)
...далее подожди пол дня и УБЕДИСЬ что хотя приложения не посылают никакий полезной информации через TCP-канал, но сёравно (через два часа) TCP-соеденение закроется само.

подумай -- "почему во втором случае TCP-соеденение закрылось а в первом нет?"

При разрыве Эзернет-соединения (!!!например вытыкни Ethernet!!! ), нисходящие сервисы посылают верхнележащим сервисам информацию о разрыве своего соединения и вышележащие сервисы также разрывают все свои соединения. У каждого стандарта есть не только протокол взаимодействия с таким же уровнем на удаленной машине, но и интерфейс взаимодействия с выше- и ниже- лежащими уровнями на текущей машине, которые реализуются так называемыми примитивами. Читайте РФС, а если не умеете, то там есть картинки и диаграммы для особо одарЁнных!!!

> При разрыве Эзернет-соединения (!!!например вытыкни Ethernet!!! ), нисходящие сервисы посылают верхнележащим сервисам информацию о разрыве своего соединения и вышележащие сервисы также разрывают все свои соединения.

мозгами сначало подумай! на том компе на КОТОРОМ ты втыкнул Ethernet -- КОНЕШНО_ЖЕ сразу [мгновенно] разрыв опредилиться. а если ты его из розетки вытынкеш -- то вообще не нада ничего даже определять.

а на том компе у коготого никто ничего НЕ_ВЫТЫКАЛ -- кто куда что пошлёт/примет?

...вот рассматриваем например ситуацию с двумя абонентами разных провайдеров, у которых у обоих белые ip (разумеется никаких nat)

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

...разумеется точно такойже эффект будет если оба компа подключены просто через Свич (но выже не доверяете Свичу, думаете он сразу начнёт всем компам рассылать что "ВНИМАНИЕ! комп №23 в дауне! его вытыкнули из разетки!")

1.

Здесь говорится не про удаленную машину, а про локальную

2.
если это TCP-соединение, то на каждый пакет ожидается подтверждение (в отличие от UDP), и если нет подтверждения в течении некоторого времени и определенного числа попыток, то соединение считается разорванным.
И это не зависимо от железа, которое стоит между двумя ПК.

3. Может Вам привести полностью работу TCP-State-Mashine ? и вообще в RFC793 все подробно написано.

> ...если не умеете, то там есть картинки и диаграммы для особо одарЁнных!!!

да, точно... нарисовал вам картинку

http://omploader.org/vNGNyZQ/%D0%BD%D0%B5%D0%B0%D0%BA%D1%82%D0%B8%D0%B2%D0%BD­%D0%BE%D0%B5-tcp.png ( http://tinyurl.com/3x95n7p )

Прикольно нарисовано!!

Бред Кипэлайв это и есть Син пакет и ответный син+аск пакет О каких ты РФЦ талдычешь

P.S. RFC ничего не требует

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

Я это к чему? Да не тяжело дописать пару строк в код, чтобы с определённым интервалом слался байт для поддержания жизнеспособности соединения. Просто это такое отступление от рфц, на которое все тихо положили, поскольку есть приемлемый workaround. Хорошая иллюстрация того, что если провайдеру лениво что-то сделать правильно, то он сделает как ему удобнее. Тем более, что проблема скорее всего кроется в дешевом оборудовании, ибо для провайдера закупить дорогое ради исправления таких мелочей - фи.

Я бы посоветовал Вам не обобщать. Или уточнять - что это касается тех провайдеров, с которыми Вам "посчастливилось" работать.

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

Но мне, как разработчику, ставят задачу - чтоб работало. Виновато железо? Да. Можно ли программно это обойти? Да. Трудно ли это сделать? Нет. Так обойди, будь добр, мы не будем клиенту парить мозги, чтобы он разбирался со своей сетью/провайдером.

Поэтому так и остаётся - включён кипэлайв на уровне протокола, а с ним еще и фейковый трафик время от времени прогоняется. И клиенты сыты, и несоответствия стандартам целы.

при работе с провайдерским nat -- разумеется посылка Keep-Alive (на прикладном уровне) -- не гарантирует что провайдерский nat не разъеденит TCP-соеденение..

...однако НЕ посылка таковых -- только ухудшит ситуацию..

получается вариант два: либо глюки, либо много глюков

а IPSEC? он не работает через NAT...

это так пользователь щитает

а провайдер хочет чтобы пользователь не только платил -- но и "ни шагу в лево, ни шагу вправо" от просмотра www в интернете!

(всё что не www -- в любую секунду может оказаться заблокированным, или не гарантированным для качественной работы )

> А чё, холодильнику дают белый адрес?

а чо -- решил "по хитрому" пробросить только один порт? и какойже именно? HTTP?

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

(а nat это синоним нестабильности и глючности сети.
конешно те люди которые всю жизнь работают через nat -- непоймут что такое "неглючная сеть". они думают будтобы постоянные разрывы TCP -- это нормальный режим работы интернета)

А блок адресов получить религия не позволяет?

Может еще и автономку зарегать ?

Автономки блоками меньше, чем /24 не выдаются. Как и BGP-анонсы не принимаются аплинками.

Цитирую его предыдущее сообщение.

То есть - это не религизный вопрос, а сугубо "экономический". Жаба душит, как говорится.

> Ты опять тот же герой, у которого неактивные tcp-сессии по два часа висят? Так с тобой не о чем разговаривать.

а ты опять тотже "умный сисадмин" который не знает тонкостей работы TCP...

...да -- разговаривать мне с тобой дествительно неочем....

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

Каким образом Вы предлагаете получать подобную статистику? От себя замечу, что когда мы подавали заявку на получение сети /17 и получения статуса LIR - одним из требований RIPE было предоставление статистики "утилизации" (использования) уже выданного блока IP-адресов. Ну нарисовал я им при помощи cacti графики загрузки по /24 - сеткам. Там, где "утилизация" была ниже требуемых 90% - просто ввел в скрипт, который при помощи rrdtool формирует графики - поправочные коэффициенты. Вот и вся "статистика". Делов-то даже для начинающего программера - на 5 минут.