Приложение, выполняющее обсчет моделей здания

[bold]Доброго времени суток всем читающим![/bold]

Требуется совет общего характера.
А именно: необходимо создать приложение, выполняющее обсчет моделей здания, структура модели не известна и определяется на этапе проектирования здания. Может быть оччень большой, однако дозволяется её (эту модель) разбить на модули, и обсчитывать на машинах в сети.
Как лучше поступить в этом случае?
Использовать RMI или ...?
Я с этим абсолютно не сталкивался, так делал мелочевку в SDK, а тут приспичило.
Самое мерзопакостное заключается в том, что может понадобится обсчитывать несколько моделей сразу, притом что основная работа (CAD) не должна прерываться.
Да еще и задел на будущее нужен: это чтобы серверная часть производила мониторинг обновления файлов клиента, и при необходимости обновляла их серверные копии...

0

RMI - это у тебя будет синхронная модель, т.е. треды будут висеть и ждать ответов, если моделей и ответов много, то и третов будет много. Сделай на событиях - ты посылаешь событие (объект, на самом деле), они тебе потом обратно. Сделай на select''ах и channel''ах, будет ресурсы есть по минимуму, работать асонхронно и максимально быстро.

На очччень умный совет не тяну, но...

0

Сообщение от Chinook RMI - это у тебя будет синхронная модель, т.е. треды будут висеть и ждать ответов, если моделей и ответов много, то и третов будет много. Сделай на событиях - ты посылаешь событие (объект, на самом деле), они тебе потом обратно. Сделай на select''''ах и channel''''ах, будет ресурсы есть по минимуму, работать асонхронно и максимально быстро. На очччень умный совет не тяну, но...

Спасибо подумаю...

0

Насколько интенсивным планируется взаимодействие между модулями?

Не стоит отбрасывать идею RMI, если использовать RMI лишь для передачи обработанной информации, то я не вижу здесь места утверждению: "треды будут висеть и ждать ответов", хотя select/channel подход и является одним из наименее ресурсоемких (т.к. это прямое использование socket''ов), но проектирование протокола общения, обработку ошибок передачи и многое другое придется программировать самостоятельно.

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

С уважением,
Владимир

0

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

0

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

to boombastik:
Насчет интенсивности взаимодействия между модулями, пока сказать сложно, по идее горизонтальных связей между модулями быть не должно, все взаимодействие должно происходить через сервер, с другой стороны с любой клиентской машины необходима возможность инициировать обсчет, и контролировать его состояние. Ко всем неприятностям добавляется еще то, что может потребоваться производить обсчет и не одной модели одновременно, а в довесок и мониторинг состояния файлов на машинах клиентов (хотя эту часть, мне кажется, лучше вынести в отдельный модуль).
JMS...надо подумать...
Спасибо Всем!

0

Сообщение от k_lexx to mselez:... to boombastik:...

Странно... Все Enter-ы сожрал, а в Konqueror-e все нормально было %(

0

Прошу еще немного пояснений, я тут немного поковырялся с сокетами вроде работает как надо, во всяком случае тестовая "коротышка", порылся в документации, и все равно остался в некотрых сомнениях - с чем все-таки удобнее работать с каналами, сокетами или все-же задействовать RMI, тем более что по первым прикидкам объем работы приблизительно одинаковый.
Или эти два механизма равноценны применительно к локальной сети?

0

Каналы, сокеты или RMI ?
Каналы - это, очевидно, имеются в виду усовершенствованные сокеты (java.nio).
Быстродействие самое высокое у каналов, а удобство программирования - у RMI.

RMI автоматически меняет протокол связи при необходимости. Например, если клиент за файерволом и не может открыть сокетное соединение, то RMI использует HTTP протокол. А всего у него штук 6 внутренних протоколов.
RMI могут быть существенно медленнее, чем сокеты, по быстродействию.

Традиционные сокеты позволяют передавать обьекты (ObjectOutputStream), а в каналах все вращается вокруг ByteBuffer и чтобы передать/прочитать обьект нужны определенные усилия.

0

PS Удобнее работать с тем, что вы лучше знаете. Мне кажется сокеты - нормальный вариант.

0

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

По поводу протоколов я бы лично не стал заморачиваться: задача явно не для публичного использования, поэтому протоколы могут быть открыты, какие надо.

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

0

[bold]Доброго времени суток всем![/bold]

Чей-то мне больше понравилось работать с сокетами, да и общественное мнение склоняется в их пользу.
Задача действительно локальная, от 5 до 25 машин в связке одновременно, за файрвол их прятать не надо, инет стоит отдельно...
Хотя надо-б еще доки почитать, может быть и каналы пойдут...
...тем более, что вот это -

Сообщение от Chinook Каналы регистрируются в контроллере, и твой код по обработке будет вызван в тот момент, когда канал заработает

мне оч-чень даже нравится.

Здесь вроде бы ясно!
[bold]RMI Отпадает.[/bold]
Остаются вопросы следующего плана:
Имеет-ли смысл парится над организацией передачи объектов через каналы или использовать отдельные сокеты?
Насколько более удобна/эффективна работа тех и других инструментов?
Мне это пока еще не очевидно, а "ошибка в начале пути" ...
... да-а-а, это почти крах проекта!

[bold]Спасибо всем![/bold]

0

Сообщение от k_lexx Имеет-ли смысл парится над организацией передачи объектов через каналы или использовать отдельные сокеты?

Каналы удобны, если вы пересылаете примитивные типы (byte, int,..), поскольку все операции ведутся через байтовый буфер. Если вы не хотите свой протокол создавать, а пересылать сразу обьекты, то проще наверное обычные сокеты с использованием ObjectStream.

Преимуществ у каналов два - прямое размещение буфера в памяти и неблокирующий режим чтениязаписи.

0

Сообщение от mselez Каналы удобны, если вы пересылаете примитивные типы (byte, int,..), поскольку все операции ведутся через байтовый буфер. Если вы не хотите свой протокол создавать, а пересылать сразу обьекты, то проще наверное обычные сокеты с использованием ObjectStream.

Не согласен. Объекты пересылать через каналы так же просто как и через сокеты:

Сообщение от mselez Преимуществ у каналов... неблокирующий режим чтениязаписи.

Согласен. Здесь подробности:
http://java.sun.com/developer/... eases/nio/
http://java.sun.com/j2se/1.4.2... index.html

The New I/O features introduced to the J2SE version 1.4 Beta release provide exciting new ways to improve the performance of your programs. By taking advantage of the new capabilities, not only will they be faster but they can be much more scalable because you won''t have to worry about tasks like one thread per connection. This is especially important on the server side, greatly increasing the possible number of simultaneous connections supported.

Так что если выбор остановили на Socket/ах, то рекомендую использовать NIO

С уважением,
Владимир

0

Сообщение от boombastik Объекты пересылать через каналы так же просто как и через сокеты:

Возможно. Я не пробовал, но натыкался на обсуждения этой проблемы. Как я понял, дело в том, что получить обьект через ObjectInputStream можно только если он полностью прочитан в буфер из сети. А это конфликтует с неблокирующим режимом работы канала, т.к. обьект может загружаться в буфер с паузами из-за задержек в сети. По крайней мере, у меня сложилось впечатление, что это отнюдь не "просто". Буду рад, если выяснится, что это впечатление ошибочное.

0

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

0

Сообщение от k_lexx [bold]Доброго времени суток всем читающим![/bold] Требуется совет общего характера. А именно: необходимо создать приложение, выполняющее обсчет моделей здания, структура модели не известна и определяется на этапе проектирования здания. Может быть оччень большой, однако дозволяется её (эту модель) разбить на модули, и обсчитывать на машинах в сети.

Я делал нечто похожее в системе, которая принимает задания на создание документов, раздает их rendering серверам в сети и принимает обратно результаты. Система построена на HTTP. Есть определенный API в форме описания XML структур запросов и ответов. Взаимодействие исключительно по схемам "послал задание-жди ответа" или "послал задание-периодически проверяй статус", причем приложение по выбору может использовать любую из двух. Чаще всего второе, потому что клиентские приложения не имеют "слушающего" порта. Web-сервера имеют, поэтому между ними используется первое.

0

[bold]Доброго времени суток Всем читающим![/bold]

[bold]to boombastik & mselez[/bold]
из вот этого (Спасибо boombastik!):

Сообщение от http://java.sun.com/developer/... eases/nio/ [bold]Socket Channels[/bold] Moving on from file channels takes us to channels for reading from and writing to socket connections. These channels can be used in a blocking or non-blocking fashion. In the blocking fashion, they just replace the call to connect or accept, depending on whether you are a client or a server. In the non-blocking fashion, there is no equivalent.

ясно что каналы могут работать как в блокирующем так и неблокирующем режиме, тогда возникает вопрос такого плана: теряются ли преимущества использования каналов при использовании их в блокирующем режиме, и насколько?
Может быть имеет смысл подтверждать доставку каждого объекта используя неблокирующий режим, или задействовать иные механизмы управления?
Да-а-а, заморочка!... %)

[bold]to mag2005[/bold]
Я в принципе так и планирую сделать...
Только вот с XML пока в раздумьях, готовить здесь, парсить там, потом наоборот...
...надо подумать, хотя гибкость управления моделями здесь будет просто великолепная, я бы сказал на высшем уровне!

0

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

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

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

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

Что касается проблемы с чтением обьектов, то не уверен, что и блокирующий режим от этого защищен. Просто не знаю. Мы пока работаем с байтами, т.е. определяем начало сообщения, ждем когда конец придет и только после этого обрабатываем. Если в буфере обнаружено начало сообщения, но нет конца, то делаем compact() . Такой подход был вынужденный, потому что компонент, который слал сообщения, был на С, а байты - они и в Африке байты. А сейчас мы и между java компонентами так продолжаем "общаться".

0

PS. Склоняюсь к мнению, что преимущества неблокирующего режима очевидны, если количество одновременно подключенных клиентов исчисляется сотнями , если не тысячами. Если их 10, то скорее всего разницы не почувствуете.

0