Что подразумевается под синхронностью.
Предположим, что N компьютеров объединены в сеть через сервер. Требуется, что бы изменение объектов на форме любым пользователем мгновенно происходили у других пользователей. Каким образом это можно реализовать? С чего начать?
Буду благодарен за ссылки.

Это сообщение отредактировал(а) former - 9.9.2009, 22:29

Первое, что приходит на ум: использование сокетов: TClientSocket & TServerSocket;
Второе: сетевая СУБД, в которую записывать вносимые пользователем изменения. На таймере в каждом открытом приложении считывать эти изменения и отображать их на форме.
Самый простой способ: общая сетевая папка, в ней файл в который записываются изменения. Опять же в таймере их считываем и отображаем на форме. Здесь нужно будет решать проблемы одновременного доступа к файлу. При работе с БД (не версионной типа MySql) такого быть не должно, поскольку там будет действовать принцип: кто последний тот и прав.

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

Уточняющие вопросы:
1. Что подразумевается под объектами?
2. Один из пользователей изменил объект. В это же время (с запаздыванием на несколько микросекунд) этот же объект изменил другой пользователь. Если сеть локальная, то скорее всего положение будет следующим:
- команда от первого пользователя отправляется на сервер.
- команда от второго пользователя отправляется на сервер(для простоты будем именовать их №1 и №2).
- №1 рассылается всем пользователям (в т.ч. и №2, возможно - за исключением №1), они меняют состояние своих объектов.
- №2 отправляется всем пользователям (в т.ч. и №1, возможно - за исключением №2), состояние объектов опять меняется (это будет почти моментально)
Результат:
у пользователя 1 будет состояние от №2 (в принципе, как и положено - команда от 2 поступила чуть-чуть позднее)
у пользователя 2 будет состояние от №1. (это в том случае, если поступающая команда не "дублируется" обратно).

Имхо, это нужно будет предусмотреть как-то...

Fedia, не подходит.
kami
1. Технологическая схема, объектами которой являются задвижки, резервуары и т.д.
Параметрами, которые необходимо передавать, являются физические величины и некоторые другие.
Другими словами это параметры для модели тех. процесса.
2. Каждый пользователь отвечает за свой участок схемы.

former, 
Тогда - чат на TCP, вместо сообщений - управляющие команды (пускай даже и текстовые, чтобы меньше переделывать. Типа "Add ZObject XParam=3211 YParam=-12 ZParam=4311". Хоть я и не люблю передавать данные текстом) и всё.
Проблемой будет непосредственно перевод действий в управляющие команды и обратно. Ну и отображение их, хотя это другая история. 

Это сообщение отредактировал(а) kami - 9.9.2009, 23:22

kami, 

Я думал так. Мат. модель обрабатывается непосредственно на сервере, а с клиентов передаются в нее изменения. Реакции этих изменений передаются обратно клиенту для визуализации.
Другими словами, если модель оставлять на каждом клиенте, то время на пересчет не будет обеспечивать синхронность. Но как в этом случае реализовать серверную часть, т.е. связать мат. модель с и предачу данных?
Стоит ли создавать отдельную службу для этих целей? Какие технологии использовать?

former,  давайте, все-таки пока отделим котлеты от гарнира (в смысле - мат.модель с ее расчетами от синхронизации приложений)   Вообще - мне это представляется так: мат. модель - черный ящик, у которого один вход (к примеру - процедура DoChanges(Changes:string) ) и один выход (событие OnChangesCalculated(VisualChanges:string) ).
В этом случае компонент-сервер чата стыкуется с мат.моделью просто "на ура": сервер чата знает о "черном ящике", что у него есть вход и назначает на себя его выход. При любом сообщении от клиента сервер чата передает данные в процедуру входа мат.модели, а когда та отработала - вызывается событие окончания расчетов. Обработанные данные черного ящика просто рассылаются всем клиентам.

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

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

Это сообщение отредактировал(а) former - 9.9.2009, 23:59

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

Добавлено через 1 минуту и 1 секунду
Сейчас попробую написать работоспособный пример.

нет, пример будет завтра (вернее, уже сегодня) вечером.
Остановился на раздельной обработке передаваемых/принимаемых данных на сервере, еще немного+пара тестов и будет готово.

Сделал.
Это адаптированные вырезки из более мощного проекта, поддерживающего приоритеты передачи данных, шифрование "на лету" BlowFish-ем и т.д.
Комментариев нет, извините. Если что-то непонятно - спрашивайте.
Тестирование проводилось на:
 - передачу данных в обе стороны
 - адекватное реагирование на разрыв соединения в режиме простоя
 - отсутствие утечек при всех действиях.
Не проводилась проверка (лень, если честно) реакции компонентов на разрыв соединения непосредственно в процессе передачи данных, но думаю - ничего страшного не будет.

Ограничение:
Не стоит (но не значит, что нельзя) передавать данные в несколько сотен мегабайт от сервера клиентам - внутреннее хранилище данных основано на TMemoryStream, что при наличии десятков подключений приведет к задействованию памяти SourceStream.Size*ClientCount. В изначальных компонентах такого ограничения нет.

Передача данных корреспонденту поддерживается несколькими методами (буфер, строка, TStream). Прием - только TStream. При необходимости - расширить на события с приемными буферами других типов несложно. У сервера есть методы "Передать всем" и "передать конкретному".

Особенность:
При передаче данных через TStream сетевой компонент становится его владельцем и САМ уничтожит его. Посему - передали Stream в метод и ЗАБЫЛИ про него.
При приеме - наоборот. Получив TStream из сетевого компонента, владелец ОБЯЗАН его уничтожить.

Пример работы с этими компонентами так же во вложении.

P.S. Надеюсь, что гуру форума также не обойдут вниманием этот файл и подскажут, где в нем есть грабли и т.д.

Это сообщение отредактировал(а) kami - 10.9.2009, 12:59

Присоединённый файл ( Кол-во скачиваний: 7 )
 SimpleTCPTransfer.zip 6,28 Kb

kami, спасибо за пример. Посмотреть теперь уже, к сожалению, смогу только в выходные.
По результатам отпишу.

 бор (с)   

Akella, вроде бы я тебя никогда плюсами в репу не обижал. И kami не обижу, когда тема будет исчерпана. Просто некоторые после повышения в репутацию сваливают из темы и получается висяк.

тише, а то нас THendle за флуд накажет   

Я бы сказал, что это не пример, а готовый шаблон для реализации Вашей задумки по