|
ru.algorithms
- RU.ALGORITHMS ----------------------------------------------------------------
From : Alex Astafiev 2:5000/228.16 21 May 2002 15:27:15
To : Aleksander Khamov
Subject : Интересно что подскажите
--------------------------------------------------------------------------------
AK> Проблемка вот в чём:
AK> Есть некий СЕВРЕР, есть КЛИЕHТ. КЛИЕHТ отправляет на СЕРВЕР
AK> некоторые ДАHHЫЕ, которые СЕРВЕР обрабатывает некоторое время, которое
AK> вычисляется исходя из этих самых пришедших ДАHHЫХ. КЛИЕHТ и СЕРВЕР
AK> могу находится друг относительно друга в режиме офф-лайн, и сами могут
AK> быть в Shutdown-е.
^^^^^^^^^^
Shutdown это не проблема. Вычеркивай это, т.к. читаем ниже. Тебя не будет
волновать shutdown сервера.
AK> По истечению времени обработки ДАHHЫХ, СЕРВЕРУ
AK> необходимо ПРИ ПЕРВОЙ ЖЕ ВОЗМОЖHОСТИ (и КЛИЕHТ и СЕРВЕР - он-лайн)
AK> передать результаты своей работы.
Это не идеология c/s.
Клиент должен запросить результаты работы. Сервер сам
ничего никуда не передает и вообще, никогда не знает каждого клиента
"в лицо". Хоть это и кажется неоптимальным на первый взгляд, это всего лишь
так кажется. Это помогает разрешить _неразрешаемую_ дилемму. Короче - забота о
своих данных - это забота клиента.
Эта задача решается, так -
Со стороны клиента
1. Клиент размещает данные в БД сервера. Это транзакция номер 1.
2. Инициирует обработку. Это транзакция номер 2.
3. Отключается на неопределенное время, хоть навсегда.
4. Периодически делает запросы серверу, справляясь о готовности его, клиентской
задачи.
5.Если задача готова - забирает свои рассчитанные данные с сервера. Это
транзакция номер 3.
6. (Сугубо опционально) Клиент может решить, что теперь можно удалить
а) входные данные транзакции номер 1. б) выходные данные, которые он забирает
транзакцией номер 3. Тут стартует транзакция 4, удаляющая эти данные.
Итого - четыре фазы. Замечу еще раз, Беспокоится о данных именно клиент.
Со стороны сервера
1. Когда приходит запрос на обработку данных, сервер проверяет, есть ли
необходимые данные, и если все готово, запускает рассчет.
2. Когда рассчет окончен, сервер располагает в специальной табличке доступной
для прочтения клиенту запись о том что данные рассчетов готовы.
Замчеу, что с тех пор как клиент передал данные, сервер больше ничего знать не
знает о нем - проблема получения данных это проблема исключительно клиента,
а вовсе не сервера.
AK> СЕРВЕР должен ГДЕ-ТО хранить
AK> промежуточные ДАHHЫЕ, например для возможности "безболезненной"
AK> перезагрузки. Упёрся я рогом вот во что: Доступ к СЕРВЕРУ (самой
AK> машине) открыт для любого
Смотря что подразумевается под сервером. Если это современная реляционная субд
- то права можно разграничивать чрезвычайно гибко. Можно построить такую
систему, что клиент будет видеть только "свои" порции данных.
AK> :( Ситуация:
AK> С КЛИЕHТА приходят ДАHHЫЕ. Hа СЕРВЕРЕ их быстро копируют и
AK> сохраняют КОПИЮ. СЕРВЕР отрабатывает ДАHHЫЕ и готов отослать их
AK> КЛИЕHТУ, в этот момент, делаем Shutdown СЕРВЕРУ и подменяем готовые к
AK> отправке ДАHHЫЕ, на КОПИЮ, созданную ранее. И работа СЕРВЕРА
AK> начинается, считай, сначала, ЧТО HЕ ЕСТЬ ГУД !!!
AK>
AK> Как с этим бороться ??? Подскажите пожалуйста алгоритм проверки
AK> подмены ДАHHЫХ. И вообще, кто что может предложить по решению данной
AK> проблемы?
это проблема так называемой транзакционности.
она несущественна в современных СУБД, таких как Oracle, MS SqlServer,
Interbase(Firebird). Если в момент размещения данных произойдет любой сбой,
хоть отключится питание системы, то сервер производит автоматический откат, и
вся база данных остается в таком виде как есть.
Почему проблема отсутсвует в случае применения транзакций:
1. Помещаем данные на сервер, если сбой - помещаем снова.
2. Данные уже на сервере, с ними ничего не случится, Запускаем обработку в
транзакции, если что-то произойдет, то транзакция откатится. Hичего страшного,
просто смотрим какие транзакции были откачены, и запускаем и снова.
3. Когда данные готовы, они уже лежат на сервере. Если что-то произойдет в
момент забора данных, то опять-таки, ничего страшного. Транзакция откатится, а
мы сможем их снова забрать в следущей попытке.
AK>
AK> Notes: ДАHHЫЕ можно не восстанавливать, просто либо КЛИЕHТ либо СЕРВЕР
AK> должен знать что они - ЛИПА.
AK>
AK> И ещё, если кто-нибудь может посоветовать какую-нибудь литературу по
AK> работе с асинхронными данными, и их шифрованием, киньте URL, название
AK> книги, текстовички, буду признателен и на каждом углу петь гимн в Вашу
AK> честь :) -- P.S.:
Если требуется security данных, то Oracle/Firebird обеспечивает достаточную
безопасность данных для военных/гос применений.
Рекомендую
http://ib.demo.ru как стартовую точку.
Delphi, как систему для программировния клиентов,
и в зависимости от серьезности / коммерч. стоимости проекта реляционную субд
Interbase/Oracle/Sybase/MsSqlServer.
AK> Если изложил проблему коряво, скажите где перефразировать - очень
AK> нужна помощь !!!
P.S. сильно когти не гну, но на западе за ТАКИЕ вот конкретные консультации
людям платят Nное количество денег. ;))) Как консультантам обладающим
волшебными знаниями, помогающими пойти правильным путем с самого начала,
что в противном случае чревато огромными потерями.
.raider =;)
---
* Origin: Alex Raider/ Flash inc. 1992-2002 (2:5000/228.16)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
