Геннадий Васильев wrote:
> C>Я уже давно понял, что делать распределенные или многопоточные системы
> C>на чем-то кроме отсылки сообщений — это обычно гиблое дело.
> Угу. Особенно, если не забывать, что потенциально любой "синхронный"
> вызов по сети может завершиться исключением.
Ну это вполне нормально — в определенных случаях.

Например, в EJB-контейнерах для компонентов обеспечивается
контролируемое окружение, и если что-то там прилетит неправильное —
контейнер все аккуратно откатит и скажет, что так и было

VladD2 wrote:
> Я имею под Виндовс все то что под Линукс и немного больше. Обратное не
> верно. А раз так, то все что можно сказать об линуксе можно сказать и о
> Виндовс.
А Reiser4FS на Винде есть? Или любая другая нормальная FS, которая не
торомзит?

Геннадий Васильев wrote:
> Не совсем так. Unix way (во всяком случае, в контексте этой дискуссии,
> как я её понимаю) не так мёртво завязан на синхронность вызовов. Что
> COM, что CORBA — одна и та же песня: синхронный вызов с непредсказуемой
> длительностью, с помощью которых ещё и эмулировать messaging приходится.
Ну так и запись в пайп — блокирующееся операция, причем еще можно и
SIGPIPE'ом в морду получить.

> Опять таки, любой вызов DCOM/CORBA может завершиться исключением, а это
> уже требует в обязательном порядке обкладывать их обработкой исключений,
> с messaging всё проще — мы сразу честно признаёмся себе, что
> длительность вызова предсказать нельзя и ориентируемся на модель: "ждём
> сообщение", а не "должно сработать!".
Ну так и с синхронными вызовами это возможно. Просто сразу говорим, что
методы могут работать неограниченно долго.

> А простой messaging по IP: сокеты плюс
> простенькая сериализация. Да и то, в случае C можно структуры данных
> почти без изменений гонять (диспетчеризация только нужна и решение
> конфликта endian-ов).
Простой-то, он простой. Да вот сильно ненадежный.

Например, сейчас работаем с заказчиком в USA — канал связи до него
паршивый. Обычное сокетное соедиенение падает где-то раз в час (из-за
чего работать через SSH особенно удобно), так что необходимы механизмы
восстановления после сбоев, а это уже не так-то и просто сделать. А если
еще failover захочется...

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

C>Ну так и запись в пайп — блокирующееся операция, причем еще можно и
C>SIGPIPE'ом в морду получить.

Если мне не отшибает память, то SIGPIPE можно получить в Unix-е и при попытке записи в закрытый сокет (или чтения из закрытого сокета, не помню точно).

C>Ну так и с синхронными вызовами это возможно. Просто сразу говорим, что
C>методы могут работать неограниченно долго.

Насколько я знаю, неограничено долго RPC вызовы не работают. Они завершаются либо с кодом ошибки TIMEOUT или с порождением такого же исключения.

>> А простой messaging по IP: сокеты плюс
>> простенькая сериализация. Да и то, в случае C можно структуры данных
>> почти без изменений гонять (диспетчеризация только нужна и решение
>> конфликта endian-ов).
C>Простой-то, он простой. Да вот сильно ненадежный.

C>Например, сейчас работаем с заказчиком в USA — канал связи до него
C>паршивый. Обычное сокетное соедиенение падает где-то раз в час (из-за
C>чего работать через SSH особенно удобно), так что необходимы механизмы
C>восстановления после сбоев, а это уже не так-то и просто сделать.

Это восстановление IP-соединения сложно сделать?
Да элементарно все делается. Даже в книгах по ACE, если не ошибаюсь, приводятся примеры того, как восстанавливать TCP/IP подключения после сбоев. И как строить приложения на основе нескольких слоев, чтобы подобные разрывы и восстановления связи не оказывали на приложение влияния.

eao197 wrote:
> C>Ну так и запись в пайп — блокирующееся операция, причем еще можно и
> C>SIGPIPE'ом в морду получить.
> Если мне не отшибает память, то SIGPIPE можно получить в Unix-е и при
> попытке записи в закрытый сокет (или чтения из закрытого сокета, не
> помню точно).
Да, или в закрытый pipe (как ни странно).

А закрытым он может стать из-за потери связи, например.

> Насколько я знаю, неограничено долго RPC вызовы не работают. Они
> завершаются либо с кодом ошибки TIMEOUT или с порождением такого же
> исключения.
Для почти всех практических целей таймаут в две минуты — неограниченно
долго

> C>Простой-то, он простой. Да вот сильно ненадежный.
> C>Например, сейчас работаем с заказчиком в USA — канал связи до него
> C>паршивый. Обычное сокетное соедиенение падает где-то раз в час (из-за
> C>чего работать через SSH особенно удобно), так что необходимы механизмы
> C>восстановления после сбоев, а это уже не так-то и просто сделать.
> Это восстановление IP-соединения сложно сделать?
Восстановление — никак. Пересоединение — можно.

> Да элементарно все делается. Даже в книгах по ACE, если не ошибаюсь,
> приводятся примеры того, как восстанавливать TCP/IP подключения после
> сбоев. И как строить приложения на основе нескольких слоев, чтобы
> подобные разрывы и восстановления связи не оказывали на приложение влияния.
Не так все просто. А если сервер перегружен и из-за этого по таймауту
отваливается? Тогда неплохо бы переключиться на резервный сервер, но
только если для сессии не установлен sticky-marker. А stateless-вызовы
можно load ballancing'ом распределять между серверами.

А еще есть failure modes, когда клиент обрабатывает сообщение, отсыла

VladD2 wrote:
> Зашибись. Значит под виндовс "java, mono, corba, XPCOM, SOAP, всё что
> угодно" не приминимы? Если "да", то откровенно говоря закрыдываются
> сомнения на счет твоего знания Виндовс.
Можешь мне поверить, товарищ kan лично использовал XPCOM, Java и COM.

> Если "нет" (т.е. применимы),
> тогда закрадывается сомнение в честности высказывания.
Вероятно, имелось в виду, что определенная реализация КОП уже намертво
защита в Винду.

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

>> Не совсем так. Unix way (во всяком случае, в контексте этой дискуссии,
>> как я её понимаю) не так мёртво завязан на синхронность вызовов. [...]
C>Ну так и запись в пайп — блокирующееся операция, причем еще можно и
C>SIGPIPE'ом в морду получить.

Хм... Вообще-то — да. Что-то меня на сокетах заклинило.

>> [...] ориентируемся на модель: "ждём сообщение", а не "должно сработать!".
C>Ну так и с синхронными вызовами это возможно. Просто сразу говорим, что
C>методы могут работать неограниченно долго.

+1

>> А простой messaging по IP [...]
C>Простой-то, он простой. Да вот сильно ненадежный.

+1 Я просто попробовал выделить основные моменты в Unix way и в вольно пояснить, почему messaging — базовый механизм по отношению к RPC.

PS.: Нет, не правильное это дело — объяснять Дао.

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

C>А закрытым он может стать из-за потери связи, например.

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

>> Это восстановление IP-соединения сложно сделать?
C>Восстановление — никак. Пересоединение — можно.

Ну да, я не точно выразился.

>> Да элементарно все делается. Даже в книгах по ACE, если не ошибаюсь,
>> приводятся примеры того, как восстанавливать TCP/IP подключения после
>> сбоев. И как строить приложения на основе нескольких слоев, чтобы
>> подобные разрывы и восстановления связи не оказывали на приложение влияния.
C>Не так все просто. А если сервер перегружен и из-за этого по таймауту
C>отваливается? Тогда неплохо бы переключиться на резервный сервер, но
C>только если для сессии не установлен sticky-marker. А stateless-вызовы
C>можно load ballancing'ом распределять между серверами.

А что такое sticky-marker?

eao197 wrote:
> C>А закрытым он может стать из-за потери связи, например.
> Кстати, такие проблемы снимаются как только начинаешь работать с сокетом
> через предварительный select для определения статуса.
Тогда надо переписывать код "наизнанку" (или использовать языки с
сontinuation'ами).

> C>Не так все просто. А если сервер перегружен и из-за этого по таймауту
> C>отваливается? Тогда неплохо бы переключиться на резервный сервер, но
> C>только если для сессии не установлен sticky-marker. А stateless-вызовы
> C>можно load ballancing'ом распределять между серверами.
> А что такое sticky-marker?
Маркер, означающий, что сессия "прилипает" к определенному серверу и не
может быть переброшена на другие load-ballancing'ом или failover'ом.

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

>> C>А закрытым он может стать из-за потери связи, например.
>> Кстати, такие проблемы снимаются как только начинаешь работать с сокетом
>> через предварительный select для определения статуса.
C>Тогда надо переписывать код "наизнанку" (или использовать языки с
C>сontinuation'ами).

Можно проще -- использовать ACE_Reactor или ACE_Proactor Или похожие собственные схемы.

>> C>Не так все просто. А если сервер перегружен и из-за этого по таймауту
>> C>отваливается? Тогда неплохо бы переключиться на резервный сервер, но
>> C>только если для сессии не установлен sticky-marker. А stateless-вызовы
>> C>можно load ballancing'ом распределять между серверами.
>> А что такое sticky-marker?
C>Маркер, означающий, что сессия "прилипает" к определенному серверу и не
C>может быть переброшена на другие load-ballancing'ом или failover'ом.

Спасибо, понял.

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

VladD2 wrote:

>> > Зашибись. Значит под виндовс "java, mono, corba, XPCOM, SOAP, всё что
>> > угодно" не приминимы? Если "да", то откровенно говоря закрыдываются
>> > сомнения на счет твоего знания Виндовс. Если "нет" (т.е. применимы),
>> > тогда закрадывается сомнение в честности высказывания.
> _>Применимы.
> Значит делаем вывод в нечестности, ну, или хотя бы в ошибочности твоих
> высказываний.
Навек позор покрыл меня.

> _> Но это заслуга этих технологий, а не винды.
> Что это тебя так перекосило? Уж не угледел ли ты чего остроумного в
> своих словах?
Простите, дяденка.

> Уж не заслуга ли Линукс в том, что эти технологии работают и на нем тоже?
Некоторые вещи пишут под линух, под винду портят. Тот же mysql/apache, объявляя, что "оно как-то работает", как никто не
гарантирует...

> _>Ты так и не понял о чём я.
> Возможно. Но понял, что суждения твои крейне противоречивы и ошибочны.
Я неудачник, убью себя на досуге.

> _> Винда — набор "всё в одном". Ставишь винду — получаешь сразу всё,
> хотя не всегда лучшего качества и не всегда адекватного. Линух —
> конструктор "собери сам", собираешь по своему вкусу, требованиям, железу.
> Высосанное из пальца утверждение. Если конечно не брать в рассчет, что
> можно заняться самостятельным потчиньем ядра.
Собственно, почему не брать? Не укладывается в твою супер-концепцию? Кстати, неплохо бы вспомнить, что винда по этому
пути "гибкости" пошла по необходимости, чтобы противостоять конкуренции. Гибкость линуксов же — by design, с рождения.

> Я имею под Виндовс все то что под Линукс и немного больше. Обратное не
> верно. А раз так, то все что можно сказать об линуксе можно сказать и о
> Виндовс.
Что "немного больше" (особенно с т.з. сабжа)?

> _>В винду встроено COM+, и отключить его просто так не получится, тебе
> оно навязано.
> Начнем с того, что есть встраиваемыме версии Виндовс в которых ни КОМ-а,
> ни даже графической оболочки нет. Так что это твое незнание проблемы
> говорит. Виндовс на КОМ не основана. Он в ней часто применяется как
> средство абстракции и компонентизации, но и только.
Если так рассуждать, то в чём тогда сабж?

> Ну, и главное. Что собственного плохого в наличии КОМ? Вот его отсуствие
> является для многих минусом.
Вообще говоря, по отношению к сабжу, то, что его считают "правильным" для винды.

> _> А некоторые дистрибы линуха вполне
> _>могут содержать какую-нидь КОП платформу, на которой дистриб построен
> (та хрень в KDE, например), но это не входит как
> _>неотъемлемая часть в линух вообще.
> И что? Какое это отношение имеет к делу и к откоровенно неверным и мягко
> говоря лукавым заявлениям сделанным тобой выше?
Попробуй порассуждать:
"КОП в винде" — такого вопроса нет. Сразу очевидно = COM, .NET.
"КОП в линух" — вопрос? Да что угодно!

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

eao197 wrote:
> C>Тогда надо переписывать код "наизнанку" (или использовать языки с
> C>сontinuation'ами).
> Можно проще -- использовать ACE_Reactor или ACE_Proactor Или похожие
> собственные схемы.
А можно еще Boost.Asio использовать

Все равно придется писать event-driven код.

> Кстати, с переключением на резервный сервер есть еще одна интересная
> деталь. Может потребоваться периодически пытатся переподключиться к
> основному серверу и, если это удалось, соединение с резервным сервером
> закрыть, а по основному соединение продолжить работу.
Еще много чего может быть

Cyberax wrote:

>> Зашибись. Значит под виндовс "java, mono, corba, XPCOM, SOAP, всё что
>> угодно" не приминимы? Если "да", то откровенно говоря закрыдываются
>> сомнения на счет твоего знания Виндовс.
> Можешь мне поверить, товарищ kan лично использовал XPCOM, Java и COM.
И юних вэй — баши, пайпы, грепы, авки, перлы и прочую [гр]адость.

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


K> А я вот ни разу от морды не плясал. Всегда плясал от workflow, логики и структур данных. Что я делал не так?
Весьма зря. Прогуглитесь на тему функционально-ориентированных метрик в предварительном планировании. Будете удивлены. И это, кстати, общепризнано и работает. Или что-то более крутое типа COCOMOII
И вообще, в приложении все должно быть таким, чтобы удовлетворяло клиента. И обивка для кресел, и мотор.

С уважением, Gleb.

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

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

А я на веру ничего принимать не буду. Я попрошу библиографические ссылки, и постараюсь убедиться, что число получено из нескольких независимых источников. И тогда степень довария к этой информации будет довольно большой. Но естественно не 100%, к фактической информации такого довария не может быть никогда просто по определению. И, кстати, чем более важна для меня информация (то есть — если она используется в моих собственных рассуждениях), тем более низкий первоначальный коэффециент доверия она получит, и тем больше усилий по проверке её мне придётся приложить. Так что да, про количество звёзд я приму с высокой степенью доверия хотя бы от того, что мне абсолютно наплевать, сколько их там видно. Мне эта информация совершенно бесполезна.

Вот если мне приведут логическую конструкцию, которую я могу независимо проверить, не зависящую от достоверности каких либо внешних фактов — тогда да, тогда я буду на 100% уверен в корректности утверждения. В случае с 2+2=4 это возможно, в случае с количеством звёзд — нет.

E> Хотя бы потому, что я могу сослаться на этого профессора.

Как сослаться? На трёп ссылаться нельзя. Ссылаться можно на опубликованный результат, прошедший через peer review.

E> Или же описание механизма исключений в C++ я предпочту прочитать в книге Страуструпа, а не в "Освой C++ самостоятельно за 21 день".

Для этого не надо никаких представлений об авторитетах. Достаточно знать, как язык реализуют, какое отношение мнение Страуструпа имеет к решениям комитета, и на кого ориентируются разработчики конкретных реализаций языка. Вся информация открытая и объективная. И авторитетность тут совершенно не при делах.

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

S>А скажите пожалуйста, вы считаете что утверждение 2+2=4 всегда и везде верно? И доказать это можете?

Когда не указано специально, считается, что применяется аксиоматика целых чисел. Обычно используется аксиоматика Пеано. В её рамках 2+2 всегда будет 4, и это доказывается элементарно. Таковы правила языка — есть набор общепринятых умолчаний. Если же будет сказано, что эта запись — на другом языке, в другой аксиоматике — то это уже будет и совершенно другое утверждение.

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

K>> А я вот ни разу от морды не плясал. Всегда плясал от workflow, логики и структур данных. Что я делал не так?
GZ>Весьма зря. Прогуглитесь на тему функционально-ориентированных метрик в предварительном планировании. Будете удивлены. И это, кстати, общепризнано и работает.

Я как бы в курсе. Ну так ведь тут мы пляшем от ФУНКЦИЙ. От бизнес-процессов, от семантики, а не от внешнего вида морды. Об что, собственно, и спич.

GZ> Или что-то более крутое типа COCOMOII
GZ>И вообще, в приложении все должно быть таким, чтобы удовлетворяло клиента. И обивка для кресел, и мотор.

Любая морда может быть прикручена. Потом. Но в проектировании мордам не место!

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

>> Проблемы возникают если про эти разделяемые ресурсы забывают при
>> проектировании, думая, что "фигня, потом приковыряем".
C>Если бы учли их сразу — то не писали бы в виде агентов.

???

C>А вот фига. Базу и так уже можно считать агентом, который отвечает на
C>запросы по некоторому протоколу. Проблема с семантикой работы с данными
C>в БД.

Для "интеллектуального" агента БД слишком сложна. Так что нет, нельзя считать. Надо упростить сначала.

C>Проблема в том, что разные клиенты могут видеть разное состояние БД
C>в зависимости от своего транзакционного состояния и состояния
C>остальных клиентов. А еще в жестоком реальном мире есть триггеры
C>в БД, хранимые процедуры и нарушения constraint'ов.

Вот именно.

C>Более того, у БД нет цельного состояния — ее корректно можно
C>моделировать в агентской парадигме только если считать каждую строку
C>отдельным агентом.

Вообще-то однозначности состояния от агента не требуется...

C>Алгоритмы становятся распределенными, если между ними есть разделяемое
C>состояние (база данных).

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

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

K>> И что же тут не так? Наблюдение моё совершенно объективное. Сторонники genuine windows way любой разговор про КОП сводят к документам и оффисам. Что характерно, сторонники unix way об этом классе задач обычно вообще не думают, он им не интересен. Гораздо более крупными системами занимаются, вестимо.

VD>А чем измеряется крупность системы?

Да хотя бы kloc. Без разницы.

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

S>>А скажите пожалуйста, вы считаете что утверждение 2+2=4 всегда и везде верно? И доказать это можете?

K> Когда не указано специально, считается, что применяется аксиоматика целых чисел. Обычно используется аксиоматика Пеано. В её рамках 2+2 всегда будет 4, и это доказывается элементарно. Таковы правила языка — есть набор общепринятых умолчаний. Если же будет сказано, что эта запись — на другом языке, в другой аксиоматике — то это уже будет и совершенно другое утверждение.

тогда чем вы можете объяснить свои категорические заявления, без ознакомления о чем (тобишь о каких условиях) речь идет?