Возвращаясь к KalpaCloud - Компьютерные священные войны

Здравствуйте, Sheridan, Вы писали:

S>Ну я надеялся какие-то вопросы задашь. Лично по мне очень нравится миниатюрность потребления траффика и легкость перехода с кутэ.

Ну вот сейчас постепенно начали появляться подробности. Почитаю, посмотрю, тогда что-нибудь спрошу.

P>>Т.е. на Java или Фортране его использовать не получится?
S>Это плохо? Как по мне это очень даже хорошо: относительно высокий порог вхождения в ц++ (а далее еще и в кутэ) отметает большинство говнокодеров. Пусть умрут.

Ты в самом деле считаешь, что на C++ не пишут говнокода?

Использование только C++, да еще с обязательным применением библиотек, не имеющих прямого отношения к технологии резко сужает круг пользователей данной технологии. Ибо если у меня, допустим, 90% кода уже написано и работает, например, на Java, то я не смогу твою разработку применить, как бы полезной она ни была. Воспользуюсь чем-нибудь еще.

И, кстати, использование Qt еще не гарантирует высокого качества конечного продукта. Пример — PC Suite от Nokia. Шикарные BSOD-ы показывал.

S>Да. При нажатии на кнопку отправляется чтото порядка 70 байт

То есть если я пишу, например, со смартфона, то каждая буква обходится с 70 байт исходящего трафика?

S>Ты так говоришь, как будто это плохо и больше ничего так не работает. Сравни с современными веб-приложениями. Таже фигня. Яваскрипт используется практически исключительно для запросов к серваку.

Я никогда толком не разбирался в WEB-программировании. Пару клиентских скриптов, однако, мне коллеги показали. У меня почему-то сложилось впечатление, что события обрабатываются на клиенте, а к серверу запросы отправляются в случае необходимости получить какие-нибудь данные, и это видно в коде скрипта. Если я наврал, пусть меня поправят.

S>К тому же куте имеет свой какойтотам скрипт и автор собирался и его прикрутить к клиенту. Я, кстати, очень против того чтобы у клиента был еще какойтотам скрипт, ибо клиентом может быть древний комп или вообще како-ть немощный планшетный пк. У сервака голова большая — вот пусть он ей и думает.

Рухнет сервак. Ты же сам чуть ниже пишешь, что автор перещел на двоичный протокол. Не от хорошей жизни, надо полагать. А в телефоны сейчас 2-ядерные процессоры ставят. Неужто не справятся они?

S>Да собственно рассказывать нечего, уже все рассказал. Это не дотнеты с виндовсформами. Или тебе начать про саму кутэ рассказывать?

Забудь.

S>Самые удобные для программирования задачи. Никаких синхронизаций с гуи и модальной фигни. Надо — написал в сислог, надо — на экран, надо — в сокет. Прямо из того места откуда надо.

Мне когда-то пришлось руками делать GET и POST, нужно было что-то от ASP получить. Их реализовать оказалось намного легче, нежели самопальный бинарный протокол.

Здравствуйте, Privalov, Вы писали:

P> После того, как я сам пару таких кустарных протоколов сделал, могу заявить — в печку. Считать байты в случае малейшей ошибки в запросе или ответе — к чертям. Насчитался. А ну как вдруг поменять чего придется в структуре. Это — адЪ.

А вот и нет. Бинарный протокол совсем не обязан быть завязанным на жесткие смещения. Он может быть так же самоописываем, как и XML.

P> А если применить старый добрый XML, SOAP — сервер ляжет.

Смотря, как парсить XML

avalon 1.0rc3 build 428, zlib 1.2.3

Здравствуйте, Sheridan, Вы писали:

S> Хотя вполне возможно сервант все таки загинается, что впрочем довольно удивительно, хотя не надо исключать возможный рсдн-эффект.
S> Там оно поднято на виртуальной машине совсем уж урезанной, памяти дай бог чтобы мегабайт 90...

Таки дело пошло. Залогинился, кнопочки потыкал, окошечки пооткрывал. Потом снова "Connection lost" и усе. Помнится, автор еще во времена первых упоминаний ведги говорил, что у него сделано восстановление сессий и что-то там с отказоустойчивостью... ихде? Но трафика и правда жреть крайне мало, однако лаги ощущаются.

avalon 1.0rc3 build 428, zlib 1.2.3

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

P>Буду признателен.

Здесь, в КСВ, шума много, конкретики никакой. На сайте автора — рекламные лозунги. Разворачивать всю среду и писать примеры у меня сейчас возможности нет и неясно, когда появится и появится ли вообще. А хотелось бы чего-нибудь определенного. К тому же мне в жизни пришлось пару раз реализовывать неизвестно кем изобретенные протоколы обмена данными между клиентом и сервером, и с тех пор я не считаю кустарщину хорошим подходом к решению подобных задач.

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

Если искать ближайший современный аналог, то Kalpa — это GWT с поправкой на то, что Kalpa не для веба/браузера. Но идея та же — пишем что-то один раз, потом оно работает в тонком клиенте хоть за миллион километров от нас.

Как мне подсказывает моя память, Kalpa началась еще для Qt 3.x, в котором была возможность описывать элементы интерфейса декларативно на основе XML и динамически подгружать/создавать их на лету. Потом пришел Qt 4, в котором эту возможность убрали, и автору пришлось немного изгаляться, чтобы заставить это все работать без встроенных средств.

На данный момент Kalpa состоит из двух частей:
— сервер, для которого, собственно, и пишется приложение
— тонкий клиент, который способен транслировать данные с сервера в создание GUI, заполнение полей, события (нажатие н кнопки и т.п.)

Для этого в Kalpa переопределена большая часть GUI-контролов из библиотеки. То есть вместо QPanel мы используем KalpaPanel, вместо QWindow — KalpaWindow, QCheckbox — KalpaCheckbox и т.п. Причина простая. В момент, когда клиент подключается к серверу, на сервере запускается новый экземпляр написанного нами приложения (делается fork процесса, емнип), в котором все действия, связанные с GUI транслируются в набор команд ля клиента, который их выполняет.

Грубо говоря, для каждого компонента переопределено, например, событие setValue:

// псевдокод
void KalpaComponent::setValue(...){
    KalpaMessage m = new KalpaMessage();
    m.set("setValue", this, Value);
    m.send();
}

Получив вызов setValue, это все упаковывается в сообщение, шлется на клиента, который распаковывает сообщение и устанавливает значение в нужном поле/компоненте.

Клиент ведет себя аналогичным способом. Абсолютно все события, которые могут происходит с клиентской стороны — onChange, onClick, onFocus и т.п. переопределены абсолютно аналогичным способом:

// псевдокод
void KalpaComponent::onClick(...){
    KalpaMessage m = new KalpaMessage();
    m.set("onClick", this);
    m.send();
}

Код пишется только один рз и только для серверной стороны, над клиентом у нас никакой власти нет. Любые изменения или события пересылаются с сервера на клиент и обратно. Все это делается достаточно прозрачно, чтобы об этом не задумываться, и не мешает основному коду и логике приложения. В частности, по сути, переопределены только методы, отвечающие непосредственно за GUI — открытие окон, скрытие/показ компонентов, установка значений в текстовых полях и т.п.

Вся засада находится в протоколе общения между клиентом и сервером. Это — простейший до безобразия XML, который выглядит примерно так:

<!-- создание формы -->
<component type="panel" id="Panel1">
  <component type="checkbox" id="CheckBox1"></component>  
  ...
</component>

Клиентский код выглядит, соответсвенно, так:

KalpaObject o;
if(type == "panel") o = new Panel();
if(type == "checkbox") o = new Checkbox();

o.setId(id);
...

события передаются точно так же:

<event type="click" id="CheckBox1">

// подобный код есть как на клиенте, так и на сервере, 
// в зависимости от событий
if(type="click") {
    KalpaObject o = MainWindow.findComponent(id);
    o.click();
}

Выглядит вся схема примерно так:
1. Клиент отослал на сервер сообщение
2. Сервер создал объект Message
3. Распаковал ответ с клиента
4. Для каждого элемента в сообщении:
4.1 Вызвал соответсвующий обработчик
4.2 Если обработчик меняет что-то в GUI, изменения записались в Message
5. Записал все, что есть в Message в XML-строку
6. Запаковал zlib
7. Зашифровал Base64
8. Отослал клиенту

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

То есть, больше ничего сверхмегасуперполезного или интересного Kalpa не предоставляет.

В протоколе есть толпа проблем:
1. Версия протокола является магическим числом, жестко прописанном в каком-то файле. То есть это реально выглядит так:

define(KALPA_VERSION, 13).

...
//где-то в коде, при полечении сообщения
if(message.getVersion() != KALPA_VERSION) return;

2. Весь XML создается в памяти з раз в виде одной строки. Соответсвенно, переать что-либо большое по сети невозможно. В какой-то момент автор реализовал передачу иконок для кнопочек и гуи, но они относительно небольшие, пакуются наверняка в тот же Base64.
3. До позапрошлого года все пересылалось в открытом виде под соусом «это безопасно». Потому что zlib+Base64 — это же безопасно

Сейчас, вроде, по умолчанию все идет под SSL

Самая главная проблема приложений на Kalpa с точки зрения пользователя: латентность. Предположим, мы щелкнули по кнопке X, и должна открыться форма:

Клиент: клик по кнопке X
      --------- event type="click" id="X" --->
                           сервер: ага, открыли форму Y
      <-------- event type="open" id="Y" ---
Клиент: окрыли форму

У меня из Швеции до Канады пинг ~160ms. То есть любое(!) действие будет происходить с задержкой 0.2 секунды. Даже банальное щелканье по чекбоксам. Когда тестировали шеридановский прототип форума это, мягко, говоря, раздражало. Пинг до него был еще длиннее.

Самая главная проблема приложений Kalpa с точки зрения сервера (может быть, ситуация уже поменялась, но не уверен): бесполезная жратва ресурсов.
На каждого клиента делается fork приложения. То есть в худшем варианте мы имеем по одной копии запущенного приложения на каждого клиента. Не говоря уже о том, что у наивно написанного приложения в таком случае сначала закончатся подсоединения к базе данных, а потм, собственно, и сами fork'и

На каждого клиента делается отдельное постоянное подсоединение. По умолчанию линуксовая система сможет обслужить максимум порядка 2000 клиентов на одно приложение. При условии, что она позволит сначала сделать 2000 fork'ов этого приложения.
Разные Kalpa-приложения должны висеть на разных портах. То есть, если у тебя есть форум и бухгалтерия, то форум должен висеть на одном порту, бухгалтерия — на другом.
Но, повторяю, ситуация с этим могла измениться.

Вот, что вспомнил

Здравствуйте, hattab, Вы писали:

H>А вот и нет. Бинарный протокол совсем не обязан быть завязанным на жесткие смещения. Он может быть так же самоописываем, как и XML.

Может. Но с ходу ни одного не вспомню. Разве что, боюсь наврать, ini-файлы в Полуоси в двоичную форму переводились. А все, что я видел, как раз было завязано на жесткие смещения, чтобы его вообще парсить не надо было.

P>> А если применить старый добрый XML, SOAP — сервер ляжет.

H>Смотря, как парсить XML

И сколько XML-ей.

S>Нарушу молчание.

M>>Шеридан не способен, потому что он этой фигней не пользовался, а если и пользовалсЯ, то без рабирательства в том, как оно работает
S>Ты неправ. Писал я на ведге и прекрасно понимаю что там было.

Не надо рассказывать сказки про прекрасное понимание. Начиная с того, что ты был уверен, что GVK (Glan Vedga Kalpa) — это не клиент-серверно приложение, продолжая сказками про гоняемому по сети графику у веб-приложений и о том, что клиент GVK ничего не рисует, до сказок, что там не будет проблем с версионностью, обновлениями, и что не нужны никакие заголовки в протоколе, уверенность, что посылка всего незашифрованным протоколом не станет препятсвием для реализации защищенной (хотя бы паролем) системы и заканчивая уверенностью, что GVK архитектурно отличается от браузера.

Цитирую, потому что это надо вешать на стенку

S> Конечно ничем, и там и там xml. Важно что дальше происходит.
S> Дьявол в деталях.
S> Браузер будет внедрять код в уже существующий dom, рендерить этот dom заново итд.
S> Клиент ведги распарсит этот кусочек xmlя, создаст контрол по правилам и положит его куда там надо.

Шеридан, ты думаешь, контролы на форме в Qt просто так сами появляются? Там точно так же есть иерархия объектов (аналог DOM'а в HTML/XML), эта иерархия точно так же менятся и корежится, когда происходят изменения и т.п.

Почти все твои «знания» о Ведге суммированы тут: http://rsdn.ru/forum/flame.comp/3389663.1.aspx Правда, ты тогда, почему-то, жутко обиделся. Как всегда, в общем-то

M>>Это типа библиотеки. Переопределены стандартные контролы, состояние которых гоняется по сети в виде примитивного протокола на основе XML
S>Уже не так. Исходников у меня нет, а автор говорит про то, что отказался от xml изза его оверхеда и перешел на бинарный протокол.

Там проблема не в XML, а в протоколе. Исходников нет, но вряд ли там что-то изменилось.

Здравствуйте, LuciferSingapore, Вы писали:

S>>Если местные разработчики не осознают того, что данная ситуация продлится до внедрения ipv6, которое уже идет — мне их жаль.
LS>Это все меняет — пишем приложение и ждем, когда же внедрят ipv6.
Нет, блин, пишем все возможные реализации всех возможных протоколов. и пишем под все это прокси. Вдруг web прикорют — будем через dns ходить, ага.
Дууумай, о чем говоришь.

LS>В стране эльфов, где везде ipv6, и где админ по первому свистку настроит на шлюзе все, что надо, может и не нужен.
Да нет, это похоже вокруг тебя мордор.

LS>В реальном мире он нужен, чтобы пользователей не распугивать. Я уже ответил на этот вопрос.
В смысле не распугивать? У него есть выбор?
Я так понимаю — выбор между нормальными провайдерами с нормальными админами и провайдерами с жопорукими админами и эти жопорукие админы чегототам жопоручат абы как, лишь бы не уволили.
Так?

LS>Ну и вообще, сравнил тоже — протокол для поддержки работоспособности сети с протоколом тонкого клиента.
dns то? ты не поверишь, сеть без него отлично живет, если нужно будет.
А вот сам то http не прикладывай ко всяким жопам.

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

К сожалению, пока есть W3C, этого не произойдет

При том, что в самих технологиях плохого ничего нет (см. HTMLayout), но что с ними делает W3C — это мрак

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Sheridan, Вы писали:

C>>>Ну вот потому Kalpa/Vegda — это и есть выкидыши.
S>>Классная у тебя логика: кальпаклауд выкидыш потому что некий шеридан не любит жаб.
C>Нет. У меня логика такая — ты не смотришь на историю с криками "а это Ява!! аааа!!!!".
Это жаба. В пень. В смысле под корягу.

C>Ну пожалуйста, есть и не Java — http://www.webtoolkit.eu/wt/examples/widget_gallery Оно начиналось ровно как Kalpa, в виде remoting-слоя для (тогда ещё) wxWindows, с тем же отсутствием успеха. Но там авторы поняли куда дует ветер и в спешном порядке переделали проект на веб-фреймворк для встраиваемых устройств.
Я рад за них. Не потянули свой протокол, перешли на веб, положили на быстродеействие (ну этоже звиздец месаджбокс больше секунды закрывается) и трафик и вовремя свалили на встраиваемые девайсы. Повезло, молодцы.
Только вот не вижу параллелей с кальпаклауд.

C>>>Нет, дело в том, что подобных подход к remoting'у просто нафиг никому не интересен.
S>>"Никому" это означает "всем не". В свою очередь "все" должно включать каждого, но оно не включает как минимум меня и автора, следовательно твое "никому" неверно.
C>Ну я же тебе привёл примеры ровно такого подхода — с тем же результатом. Тебе напомнить определения безумия от Марка Твена?
Ты мне напомни где привел.

C>>>На 1Гб памяти для клиентских рабочих станций?
S>>О да, браво, бурные овации. 1гб оперативки значит это раз плюнуть, а вдвое выросший объем клиента ведги (целых 2 мегабайта, ужас) — очень, очень плохо. Да?
S>>Двуликость налицо, простите за каламбур.
C>Можешь мне показать, где я что-то говорил про размер дистрибутива? Он таки да, пофиг. Не пофиг то, что смысла от этого особого нет.
Не ты. Посрись на эту тему с DOOM. И кстати, раз ты с ним несогласен в этом отношении — почему не возразил ему? Или твоя цель другая — кальпаклауд коричневеньким облить?
Раз ты молчал — я был уверен, что ты с ним согласен, отсюда и упрек в двуликость.

Здравствуйте, Real 3L0, Вы писали:

R3>В Г+ писал, чо это похоже на XUL, который вроде того (или нет?). Автор не понял.

Ну так напиши подробнее.

Здравствуйте, Sheridan, Вы писали:

S>>>Классная у тебя логика: кальпаклауд выкидыш потому что некий шеридан не любит жаб.
C>>Нет. У меня логика такая — ты не смотришь на историю с криками "а это Ява!! аааа!!!!".
S>Это жаба. В пень. В смысле под корягу.
Дальше-то что? Оно работает ровно точно так же, как и Kalpa. Может стоит таки подумать почему оно не пошло в массы?

C>>Ну пожалуйста, есть и не Java — http://www.webtoolkit.eu/wt/examples/widget_gallery Оно начиналось ровно как Kalpa, в виде remoting-слоя для (тогда ещё) wxWindows, с тем же отсутствием успеха. Но там авторы поняли куда дует ветер и в спешном порядке переделали проект на веб-фреймворк для встраиваемых устройств.
S>Я рад за них. Не потянули свой протокол, перешли на веб, положили на быстродеействие (ну этоже звиздец месаджбокс больше секунды закрывается) и трафик и вовремя свалили на встраиваемые девайсы. Повезло, молодцы.
У меня на Кальпе оно на пару секунд подвисает.

C>>Ну я же тебе привёл примеры ровно такого подхода — с тем же результатом. Тебе напомнить определения безумия от Марка Твена?
S>Ты мне напомни где привел.
Remote SWT, Remote AWT, Wt, Display PostScript, классический X — большая часть из них даже нишевыми решениями не стали.

C>>Можешь мне показать, где я что-то говорил про размер дистрибутива? Он таки да, пофиг. Не пофиг то, что смысла от этого особого нет.
S>Не ты. Посрись на эту тему с DOOM. И кстати, раз ты с ним несогласен в этом отношении — почему не возразил ему? Или твоя цель другая — кальпаклауд коричневеньким облить?
Мне лень с ним спорить, я не считаю размер дистрибутива чем-то особым.

S>Раз ты молчал — я был уверен, что ты с ним согласен, отсюда и упрек в двуликость.
Сорри, тут Кальпу защищаешь ты. Но пока это лучше у Мамута получается.

H>>А вот и нет. Бинарный протокол совсем не обязан быть завязанным на жесткие смещения. Он может быть так же самоописываем, как и XML.

P>Может. Но с ходу ни одного не вспомню. Разве что, боюсь наврать, ini-файлы в Полуоси в двоичную форму переводились. А все, что я видел, как раз было завязано на жесткие смещения, чтобы его вообще парсить не надо было.

Есть еще EBML (extensible binary markup language), который в Matroska кодеке (mkv) используется. Не знаю, насколько он самоописываемый, правда

S>> Хотя вполне возможно сервант все таки загинается, что впрочем довольно удивительно, хотя не надо исключать возможный рсдн-эффект.
S>> Там оно поднято на виртуальной машине совсем уж урезанной, памяти дай бог чтобы мегабайт 90...

H>Таки дело пошло. Залогинился, кнопочки потыкал, окошечки пооткрывал. Потом снова "Connection lost" и усе. Помнится, автор еще во времена первых упоминаний ведги говорил, что у него сделано восстановление сессий и что-то там с отказоустойчивостью... ихде? Но трафика и правда жреть крайне мало, однако лаги ощущаются.

Товарищ, роясь в сегодняшнем окаменевшем г... © Маяковский

Я тут копался в преданьях старины, так вот про восстановление сессии так никто и ничего не сказал. Было типа «клиент не разрывает соединения с сервером»

А лаги — это да. Латентность штука хорошая и очень злая (тут, под конец)

Здравствуйте, Sheridan, Вы писали:

R3>>В Г+ писал, чо это похоже на XUL, который вроде того (или нет?). Автор не понял.

S>Ну так напиши подробнее.

Это не надо ни мне, ни автору.

S>>Ты так говоришь, как будто это плохо и больше ничего так не работает. Сравни с современными веб-приложениями. Таже фигня. Яваскрипт используется практически исключительно для запросов к серваку.

P>Я никогда толком не разбирался в WEB-программировании. Пару клиентских скриптов, однако, мне коллеги показали. У меня почему-то сложилось впечатление, что события обрабатываются на клиенте, а к серверу запросы отправляются в случае необходимости получить какие-нибудь данные, и это видно в коде скрипта. Если я наврал, пусть меня поправят.

Так и есть. Если это, конечно, не классический сайт в формате «один ресурс — одна новая страница на HTML». Запросы в 70 байт конечно не уложатся, но и позволяют намного больше — от прозрачной аутентификации до сохранений ресурсов сервера посредством Cache-Control, IfMatch, Accept/Content-Type и прочих ETag'ов например, по этой схеме.

Здравствуйте, hattab, Вы писали:

H>У меня кеширующая прокся HandyCache, раньше траффик экономила, сейчас рекламу и всякие мордобуколайки режет.
ну или так, да. Я тут уже вторую неделю никак руки не дотяну к написанию конвертера из easylist в сквид.

S>> Издержки тугорукости админов?
H>Все очень просто, у HTTP(S) проксей есть возможность создавать туннели для не HTTP протоколов. У меня ася через эту проксю спокойно ходит.
блин...
ЗАЧЕМ?????? ЧТО МЕШАЕТ НАПРЯМУЮ????
так видно и понятно?

S>> Так всетаки огнестенка есть? Иначе чем порт то смаппил? и чем прикрыл остальное?
S>> Кстати, а зачем маппить то? iptables -s мойip/32 -dport 15004 -j ACCEPT
H>У прокси есть функции маппинга (это годный прокси).
щито??? (полез в сайт хандакеша)
Итить. У нее даже гуй есть... Расстрелять. Потом в кислоту, в бочку и в море.
Прокси это сервис, который должен быть на шлюзе... Впрочем, вам виндозовым трогателям меня не понять....

H>А закрывать что-то остальное мне нет нужны ибо за провайдерским натом меня ничто не пугает.
што???? Мой тебе совет: меняй провайдера. Нахрена юзеров за нат то? Я бы на разборки пошел, по крупному. С бумагами "договор о доступе к интернетам" и документацией, подтверждающей что у меня например nntp и ssh с rdp и vnc не работает, на такойто сайт на такойто порт не цепляется итд. Причем в суд сразу.
Меняй провайдера.

H>И да, достань голову из задницы, большинство сидят не под линуксом т.ч. показательно давая свои линуксовые советы
Ты понял суть комманды написанной? Я думаю что всетаки понял. Чай всетаки итшник какимто боком. Результат достигнут. К чему упрек?

H>ты рискуешь, с вероятностью 99%, попасть пальцем в жопу.
Гм, интересно это больно или наоборот... ))

S>> Кому поддерживать? кальпаклауду чтоли? Зачем?? Чтобы оправдать кривожопость админов?
S>> Так надо админов анально карать, а не самому в позу становиться, чтобы получить желаемое.

H>Софту сетевому давно пора уметь ходить через прокси (это таки стандарт). И нормальный софт таки умеет (великое дело дернуть HTTP CONNECT для создания туннеля

). А ситуации у всех разные, и не тебе судить о кривотамчеготости.

да нет. Это я так понял у тебя крупная проблема с провайдером, который посадил тебя за нат, а ты облизываешь. Не перекладывай свои проблемы на остальной мир. И меняй прова или собирай документацию и в суд, требуй внешний ип.

S>> H>Кстати, у меня мегабитный 3G, клиент теряет коннект на логине. Окно логина, при этом, кнопкой "Выход" не закрывается. Ну дела...
S>> Нестабильный коннект?
H>Вполне себе стабильный.
H>Торренты качаются,
им побоку нестабильность
H>мыло ходит,
Также побоку, тем более что постоянного коннекта ни к smtp ни к pop3 нет
H>веб серфится,
вообще побарабану на стабильность. Я посередине закачки страницы перегружаю интерфейс на шлюзе — все свокойно догружается, ибо коннект там далеко не один итд
H>авалон форум тягает,
постояно 24*7 висит окно синхронизации?
H>аська приконнекчена.
емнип она года 4 назад была вполне устойчива к нестабильному линку...

Впрочем как я говорил вполне возможен второй вариант. либо твой хандикеш тааааааааааакой хандикеш... Сдается мне так оно и есть.

	От:	Privalov
	Дата:	11.01.12 19:06
	Оценка:

	От:	Privalov
	Дата:	11.01.12 19:15
	Оценка:

	От:	Privalov
	Дата:	11.01.12 19:48
	Оценка:

	От:	hattab
	Дата:	11.01.12 20:00
	Оценка:

	От:	hattab
	Дата:	11.01.12 20:12
	Оценка:

От:	Mamut	http://dmitriid.com
Дата:	11.01.12 20:30
Оценка:	7 (4)

От:	Real 3L0	http://prikhodko.blogspot.com
Дата:	11.01.12 21:26
Оценка: