|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Zahar Kiselev 2:5030/382.1 18 Oct 2005 03:25:58
To : Kirill Frolov
Subject : Re: Дык на чём остановиться?
--------------------------------------------------------------------------------
Oct 18 01:08 05, Kirill Frolov wrote to Artem Chuprina:
KF> тянется раза в ~4 дольше, чем через fido-протоколы. Тот же suck
KF> занимает
KF> модемный канал (в любом показометре видно хорошо) где-то на 50%. БЕЗ
KF> УПАКОВКИ, кстати. Потому как линухный pppd отказывается упаковывать с
KF> имеющимся провайдером. Даже с двумя разными. NNTP паковки не умеет.
Hу вообще-то v42b должен паковать, но пакует он посредственно.
У pppd проблемы пожалуй что только с теми провайдерами, у которых
"микрософтовская" упаковка и больше никакой(питерский Скайлинк например).
Как минимум с WebPlus у него упаковка работает.
KF> Зато умеет почту отдавать медленно и нудно по одному сообщению --
А вот это да, действительно гадость.
Причем основная задница в том, что у провайдера (для примера тот же вебплюс)
стоит крутое коммуникационное оборудование, в котором буферы килобайтов на
дцать. От этого плохо(медленно) работает все, что требует частого взаимодействия
"вопрос/ответ". Это если качаешь один огромный файл по http -
то он "со стороны интернета" заливается сразу большим куском в этот буфер,
а потом с модемной стороны из него вытекает с максимальной скоростью на которую
способен модем. Обратно идут весьма редкие ACK, которые заливающий сервер не
ждет для того чтобы залить следующий кусок. Hу то есть он их ждет конечно, но
"долго и лениво", продолжая в это время лить данные.
Если же сервер хочет что-то "услышать" на каждый кусок данных небольшого размера
- дело хуже. Он кидает этот кусок данных в сторону модемного юзера - кусок
проваливается в буфер коммуникационного оборудования со скоростьб стомегабитного
эзернета. Все, таймаут у сервера пошел, он уверен что отправил
данные юзеру и ждет от него ответ. Дальше ничего не посылат. Модемный же юзер
данные еще не получил, у него может вообще на модеме ретрейн случился, данные
они где-то там посередине в канале болтаются:) Соответственно отвечать серверу
он и не думает - ибо не на что еще отвечать. Данные дойдут - ответит, хорошо
если сервер этого дождется. То есть в одном логическом канале мы имеем мало того
что два участка с абсолютно разными характеристиками(эзернет и телефонную
линию), так еще и буфер посередине.
"чистый" tcp даже на таком странном канале живет довольно прилично, у него все
же интеллекта достаточно чтобы и к такому подстроиться,
однако если поверх собственно tcp оказывается что-то примитивное типа nntp или
даже той же Гидры с небольшим размером пакета, что требует частой посылки
подтверждений или команд на ту сторону - то тормоза гарантированы.
KF> GPRS ещё более невыгодно и дорого получится в силу
KF> тех же недостатков NNTP. Разве что в on line читать.
Вообще я тут почитал описания AT-команд gprs-модемов - там упаковка теоретически
предусмотрена. Только вот я не слышал чтобы кто-то из наших операторов ее
поддерживал. Так что я задумываюсь о пакующем туннеле на основе openvpn.
"двухточечный" туннель я настраивать умею, но хотелось бы разобраться как
запустить на машине стоящей на толстом канале "туннельный сервер", на основе
которого можно создать виртуальную сеть. Только там с ssl некоотрые заморочки
имеются, я не очень хорошо пока понимаю как это работает, копаться надо. К тому
же оказалось, что в комплекте с openvpn поставляется один вариант ssl, в
комплекте с Апачем - другой, они при установке на одной машине пытаются
подраться один с другим за одни и те же каталоги и конфиги. Тут бы разобраться
как один и тот же ssl для обоих случаев применить чтобы два не держать.
KF> мучения с magic numbers, недоступность части конференций... У фидо
KF> правда тоже, мучения с подпиской и отпиской. Всё хреново, жизнь
KF> дерьмо.
А чего в фидо мучаться? Hаписал ареафиксу что надо - он и сделал.
Главное найти босса/аплинка где все нужные эхи есть.
Zahar
--- Msged/LNX 6.1.1
* Origin: mobile point - Compaq Armada 1750 + Siemens ME45 (2:5030/382.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
Re: Дык на чём остановиться? 
