Персональный проект Александра Чижова, Иркутск 1998-2006Компьютерный журнал Cooler | скачать новые компьютерные игры | гаджеты | астрономия | обзоры программиста System's temperature
recent issueaboutarchiveLive TAMrubricatorlinksBooks digestComments
Компьютерный журнал "Cooler" Александра Чижова (Иркутск)
  
prev 10 декабря 1998 next
N47
"Мышке 30 лет!"

9 декабря 1968 года было представлено устройство, которое оценят в полной мере только лет через 20. А через 30 уже не будут представлять себе жизни без него :))
First MOUSE!
вот он - первенец

Мышка показана перевернутой. Как видите, никакого шарика не было и в помине.  ...Как она ездила-то? ;))
По сравнению с ней, "крысы" от ЕС1841 покажутся суперстильными устройствами :)) Одним из "отцов" мыши является Douglas Engelbart (Дуглас Энгельберт), со странички о котором и была взята эта иллюстрация.
Так что, С Днем Рождения тебя, Мыша!
картинку прислал Eugene Meyerzon

Сисадминские байки

Работа сетей достаточно сложная штука. Хотя бы потому, как IP протокол сам по себе асинхронен. Т.е. посылающая сторона должна ждать подтверждение от принимающей стороны. Есть конечно, еще и UDP протокол, который подтверждений не требует. Этим протоколом общаются между собой сервера для обмена информацией по DNS. Ну, про UDP позже, а вот насчет IP - подробнее:
Разберем простой пример: у вас модем на 33600 (до провайдера), и у провайдера канал "наружу", допустим, 2Мб. Вы в настоящий момент вытягиваете тяжелый файл с сервера, находящимся где-то далеко. Скорость download'а в идеале будет примерно 3.5кб/с (сжатого файла). Т.е. ваша машина будет получать от модема 3.5 кила в секунду. Но вот с "того" сервера, откуда производится download - с какой скоростью будут уходить пакеты? И как вообще, _ваши_ 33600 умещаются в провайдерском канале 2Мб? Может это как-то ограничено?
 
Важно представить себе работу протокола, чтобы немного разобраться с этими "простыми" вопросами. Наверное, не стоит представлять себе "толстый" канал провайдера, как содержащий в себе кучу маленьких подканальчиков на 33600, 14400 и т.д. по числу пользователей. Скорее, это будет просто совокупность хождения всех пакетов туда-сюда.
Хм... вообще, я эту прелюдию написал, чтоб немного самому раскачаться. Тут вот какой момент: если вы допустим, "сказали" далекому серверу подать вам вооон тот файл, и он начал его добросовестно вам передавать, и совсем не знал, что после 2-3 минут передачи у вас отрубят свет, произодет крах вашей системы или еще какая бяка, которая временно или надолго отрубит вас от сети. Куда денутся пакеты с информацией? И вообще, как серверу узнать, что вы все еще хотите принимать файл или уже нажали "Cancel", потому как поняли что энное количество мегабайт со скоростью 4б/с вам еще долго не вытянуть... И почему при закачке файла (к вам) по ftp скорость сначала растет, а потом может и упасть? Почему она вообще, сначала растет?
Попробую ответить так: потому как удаленный сервер не знает, на какой скорости вы подключены и начинает слать вам пакеты, скажем по 700 байт, а после того, как придет подтверждение, он уже решает, повысить размер пакета или нет. После того, как ваша система приняла пакет с информацией, она должна отослать подтверждение о приеме тому серверу, откуда она этот пакет получила. Это и есть асинхронная передача данных.
 
Но существует еще и такое понятие, как время жизни пакета - TTL (time to live) - оно устанавливается в каждом пакете для того, чтобы не засорять сети "умершими" данными. Причем, когда такой пакет находясь даже уже в пути, в маршрутизаторе, исчерпает свое время жизни, маршрутизатор его преспокойно грохнет. Посему, если вы приняли пакет, отослали на него подтверждение и "тот" сервер послал вам следующий, а вы в это время как раз скоропостижно "рухнули", то пакет умрет, а "тот" сервер, не получив ожидаемого подтверждения, успешно закроет сессию. Умер, так умер. Но только попеременно передавать-принимать пакеты с подтверждениями немного неинтересно. Гораздо красивее запустить какую-то кучку пакетов, а потом получать на них подтверждения. Так и образуется стек FIFO (первым вошел-первым вышел) IP пакетов. Которые гуськом торопятся попасть к вам в тачку. Опять-таки, торопиться они могут перегоняя друг друга, фрагментируясь и дефрагментируясь по дороге, а нормальное фифо собирается tcp логикой уже из приемных буферов. И, кстати, нюкалка teardrop основана на неправильном задании размеров фрагментов пакетов, отчего у сборщика крыша съезжает напрочь и ваша тачка честно виснет.
В TCP есть такое понятие, как "окно". Это значит, что передающая сторона передает несколько пакетов, не дожидаясь подтверждения на первые пакеты. Т.е. с передающей стороны уходит сразу достаточно большой кусок данных, которые оседают в различных буферах пока не протиснутся в клиентские 33600. Для вышеупомянутого "окна" существует механизм регулирования в зависимости от скорости в канале передачи.
 
Очередь большой не делается, а делается она исходя из некоей статистики, собранной за предыдущее время - так сервер пытается понять, с какой скоростью и какого размера пакеты вы успеваете прокачивать. А вот если попадется такая ситуация, что половину из пакетов стоящих в очереди вы приняли, а на следующем пакете получился облом (ну не принялся он...). Что произойдет с остальными пакетами стоящими в очереди? Они благополучно умрут, т.к. на сервер от вас пойдет команда перепослать пакеты с номера такого-то, начиная с того места, где произошел обрыв, а эти пакеты бросят умирать.
 
Подводя итог, можно сказать, что скорость выкачки зависит: от того, насколько быстро приходят пакеты к вам, от того, насколько быстро доходят от вас подтверждения на них другому серверу. Следовательно, если на канале "висит" много пользователей и особенно таких, у которых скорость выше чем у вас, то их пакеты будут  ходить чаще (у них ведь время ответа будет меньше), и следовательно, ваши пакеты могут не успевать проскакивать между потоком их пакетов и будут тормоза. Что и можно наблюдать на загруженных серверах или каналах. Пробки как раз и возникают таким образом - стоит пакетам скопиться где-нибудь и - все. Особенно, если из-за этого маршрутизатором будет сброшен какой-нибудь пакет соединения, тогда приемник (ваша тачка) подождет еще некоторое время (таймаут) в надежде дождаться отброшенного пакета, и только после этого пошлет запрос передатчику на перепосылку утерянного пакета.

Продолжение еще будет...

В сегодняшнем трепе
прнимали участие: Олег, Андрей, Макс.
Тут вот у меня мыслишка появилась... Предпосылка такая: люди, пишущие софт, с самого начала ориентированный как freeware, скорее делают его для себя. Но все-таки думают, что он и кому-то еще может понадобиться. Как следствие, можем видеть нечто вроде www.freeware.ru. Но вот иногда возникают потребности во вроде бы несложных программках, но которых или нет нигде, или они достаточно специфичны (для узкого круга специалистов).
А может, что-то и есть, но не все про это знают. Ситуация с софтом сейчас скорее такая: "..а вот программка есть, делает вот это... надо кому?". А не повернуть ли другой стороной: ".. а вот надо вот такую программку, чтоб делала вот это... есть такая?".
Поэтому есть задумка сделать небольшую доску объявлений (отдельной страничкой), где можно было бы размещать "заказы" и ответы на них. Причем, скорее всего "заказы" будут не столь уж специфическими, поэтому наверняка кто-то найдет для себя что-нибудь полезное.
Какого вида заказы...? Ну, вот например: простенькая программа, которая могла бы делать следующее - проверять html код на несуразности вот такого типа: <br><font color="#222223">&nbsp;</font>. Очевидно, что тэг <font> здесь лишний. (Такие штуки композер любит стряпать). Если страничка большая, то уже тяжело с ней общаться. И вообще, чистить код от всякой левой чешуи... Обычные программы, которые я видел, делают далеко не все или не то что надо. Ну не в ворде же замену делать регуляром?
Или например, записная книжка типа TreePad, но с возможностью вставки картинок. Т.е. конечно можно использовать и Wordpad, но древовидная структура позволяет не беспокоиться о запоминании кучи имен файлов...
Иногда, кстати, идея всем полезной программы висит в воздухе, ее просто никто не может сформулировать. Или сформулировать-то может, но донести до всех - не может. Может попытаться дать такую возможность?
интересно было бы услышать Ваши мнения.
U2 "Please" (4.7Mb) ID3_tag, 128kbps, 16 bit, stereo, 44кГц (plugger)
А канал ростелекомовский на Иркутск лежит.На профилактике, говорят... Спиртом оптику протирают :)) Работаем по запасному... Тормоза...
Сегодня вроде обещали включить... в 21-00 по Москве.
"QO7012" - серийный номер к jpeg optimizer'у. После регистрации включается возможность batch обработки.
Relax!

prev

[ Архив+поиск ]-[ все комментарии ]-[ Жизнь ТАМ ]
[ Хакеры ] [ Журнал WebSound ]
[ обзор книг ] [ mouseimp ] [ биржа труда ] [ Ссылки ]
[RSS feed simple]    [RSS feed simple 2]    [RSS feed complete]

next
Универсальный измеритель
Универсальный измеритель


роботы игрушки
роботы игрушки


найди птичку
найди птичку


CrossPad
CrossPad


MEMS
MEMS


развлекаемся
развлекаемся


mini-ITX
mini-ITX


  Пишите! Мне интересно будет Ваше мнение, замечания и пожелания. Указывайте в письме НЕсогласие на опубликование. Если ничего не будет указано - публикую по своему усмотрению. Если письмо не личное, конечно...
 Журнал поддерживается ISP Деловая Сеть-Иркутск
X-ChangeEZHE
CoolerКомпьютерная Столица - товары, цены, горячие новости
Cooler (c) Alexander Chizhov, 1998
Градиент
Компьютерный журнал "Cooler". Авторство и выпуски Александр Чижов. Иркутск
1998-2009
Рейтинг@Mail.ru
Cooler
WWWoman - лучший WM!!
Exler.RU
EZHE
Rambler counter PcTuner.Ru - Компьютерные TV и FM тюнеры InterComp - Все о компьютерах

iXBT compatible award

Журнал поддерживает Иркутская фирмаDARS