выбор технологии для обмена данными

← →
Alexandr © (2005-12-06 11:48) [0]

подскажите, что проще испрользовать для написания такого.
1) рабоатем через интернет.
2) будет сервер - обработчик запросов.
к нему должны подключаться клиенты для отправки запросов и получания ответов. При этом здесь должна быть авторизация и шифрование траффика. В основном сервер будет возвращать одну запись или таблицу. При этом таблиц разных может быть ну штук 5, не больше.
3) сам клиент может быть различным. Хотя в первую очередь он будет на delphi.

Технологий то для этого очень много. А вот что использовать проще, для чего есть quick start guide. Вроде как совершенно типовая задача в 21 веке. :)

← →
Digitman © (2005-12-06 12:03) [1]

> 1) рабоатем через интернет

значит, в соответствии с моделью OSI, базовым протоколом д.б. один из протоколов 3-го уровня, например, IP (см. http://www.citforum.ru/nets/switche/osi.shtml)

> 2) будет сервер - обработчик запросов

здесь на сцену выходят OSI-уровни >= 4

> 3) сам клиент может быть различным. Хотя в первую очередь
> он будет на delphi

в огороде бузина, а в Киеве дядька)

какое отношение среда разработки клиента имеет к спецификации того или иного протокола ?

никакое !

← →
Alexandr © (2005-12-06 12:08) [2]

согласен.
Более менее определился.
используем SocketClient SocketServer
Для шифрования используем SSL
но вот вместо SSL нели чего другого, чтоб без dll внешних обойтись?

Насчет п3. Да, прогнал чего-то. :)

← →
Плохиш © (2005-12-06 12:12) [3]

WebService

← →
Digitman © (2005-12-06 12:24) [4]

> вместо SSL нели чего другого, чтоб без dll внешних обойтись?

и снова - в огороде бузина, а в Киеве дядька)

ну какое отношениеспецификация некоего протокола имеет к месторазмещению кода, реализующего некий алгоритм ?

← →
Alexandr © (2005-12-06 12:31) [5]

Сергей, я понимаю что достигший совершенства не понимает глупых вопросов, но все же...
P.S. Я бы с радостью почитал пару грамотных статей по теме. Если б они были.

Я ж просто просил чтоб меня быстро наставили на путь истинный. Ну не хочется мне углубленно изучать все технологии, чтоб потом из множества выбрать подходящие.
Я готов изучить только то, что тут применить удобнее.
пока остановился на IdTCpClient, IDTCPServer, IdSSLIOHandlerSocketOpenSSL
и файликах libeay32.dll и ssleay32.dll .

поскажите хоть, правильным ли я путем пошел, или есть что-то более высокого уровня, с чем проще будет?

← →
Плохиш © (2005-12-06 12:33) [6]

> Alexandr © (06.12.05 12:31) [5]
> то более высокого уровня, с чем проще будет?

Проще не будет, думать при любом способе придётся!

← →
Digitman © (2005-12-06 12:37) [7]

> Alexandr © (06.12.05 12:31) [5]

ты бы сначала определился с функциональностью клиентской стороны ...

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

одним словом - исходных данных крайне мало ...

← →
Reindeer Moss Eater © (2005-12-06 12:40) [8]

>В основном сервер будет возвращать одну запись или таблицу.

web сервер + браузер и все.

← →
Alexandr © (2005-12-06 12:41) [9]

функциональность простая. Но клиент должен быть в дельфи.
Браузер не пойдет.
Хотя в дельфи можно написать парсер того, что сервер выдает - хоть html, хоть xml
и сделать и браузер и дельфи. И так и этак.

← →
Reindeer Moss Eater © (2005-12-06 12:42) [10]

TidTCPServer + TidTCPClient

+ SSL

либо криптозащита прикладных данных с помощью MS Crypto API

← →
Digitman © (2005-12-06 12:48) [11]

> Браузер не пойдет

почему ?

← →
Alexandr © (2005-12-06 12:49) [12]

о, сенкс. ну я и сам уже примерно до того-же дошел.
Тперь я так понимаю, надо выработать протокол опять более высого уровня. Уже уровня команд.
Как вариант тут xml.
Хорошо, с этим понятно.

далее еще пара вопросов.
1) А на каком слое тут авторизацию делать?
2) а где почитать про ключи SSL.

← →
Alexandr © (2005-12-06 12:50) [13]

> Digitman © (06.12.05 12:48) [11]

потому что неудобно. Давайте замнем этот вопрос для ясности. :)

← →
Reindeer Moss Eater © (2005-12-06 12:52) [14]

1) А на каком слое тут авторизацию делать?

на последнем

← →
Alexandr © (2005-12-06 12:53) [15]

гуд, с авторизацией понятно. я так и думал.

← →
Плохиш © (2005-12-06 12:59) [16]

> Alexandr © (06.12.05 12:41) [9]
> функциональность простая. Но клиент должен быть в дельфи.
> Хотя в дельфи можно написать парсер того, что сервер выдает
> - хоть html, хоть xml

Я последний раз навязываюсь, но в D7 в WebService это всё уже сделано.

← →
Digitman © (2005-12-06 13:00) [17]

> Alexandr © (06.12.05 12:50) [13]

> неудобно

кому ?)

напрасно ты сразу отметаешь сей вариант ..

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

берешь тот же Апач как Web-сервер, берешь те же DevExpress-компоненты, пишешь на базе этих компонентов ISAPI-модуль (или SO-модуль - это на вкус), подключаешь к Апачу - и все ! ... и все готово уже) ... осталось одним из станд.браузеров сделать соотв.гипертекстовый запрос к Апачу ... и не надо думать ни про транспорт, ни про секъюрити, ни про визуализацию данных (ни на той ни на другой стороне) - все за тебя давным-давно уже сделано, тебе остается сосредоточиться лишь на бизнес-логике

← →
Alexandr © (2005-12-06 13:11) [18]

> Digitman © (06.12.05 13:00) [17]

да людям которым потом целый день в вебе через модем работать.

Хотя, согласен это очень неплохо. Но это не для нашей глубинки ;)

> Плохиш © (06.12.05 12:59) [16]

SOAP? Надо подумать. С одной стороны задача довольно простая, и написать самому верхний уровень несложно. И потом расширять можно как угодно. А с другой стороны, вроде да, вроде все там есть. Но этож изучать надо долго такую штуку.

← →
Digitman © (2005-12-06 13:13) [19]

> Alexandr © (06.12.05 13:11) [18]

не понял ... какое отношение имеет модем ко всей этой петрушке ?

← →
Alexandr © (2005-12-06 13:55) [20]

скорость, необходимость постоянного соединения.

← →
Digitman © (2005-12-06 14:11) [21]

> Alexandr © (06.12.05 13:55) [20]

странный ты товарисч)..

ну какая, спрашивается, разница, какими техн.средствами будет переданы данные запроса и получены данные результата запроса ?

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

← →
Alexandr © (2005-12-06 14:32) [22]

неправда.
браузер не подразумевает хранение таблиц на клиенте.
В отличие например от midas (не более чем для примера).

Т.о. поскольку раьбота будет вестись со справочником объемом пару мег, то в случае того же madas постоянный коннект ненадо, можно загрузить справочник и работать себе спокойно, потом подключился, обменялся данными ( а пока обмен идет и чаю попил) и снова отключился.
А в случае браузера прийдется висеть постоянно на связи. И по каждому движению ждать обновления страницы.

← →
Digitman © (2005-12-06 14:53) [23]

> браузер не подразумевает хранение таблиц на клиенте

твое определение таблицы ?

> в случае того же madas постоянный коннект ненадо, можно
> загрузить справочник и работать себе спокойно, потом подключился,
> обменялся данными ( а пока обмен идет и чаю попил) и снова
> отключилс

так-с ... подробности таки пошли) ... оказывается клиентские НД должны допускать редактирование ... из тебя такие ВАЖНЫЕ подробности нужно клещами вытягивать ?

> в случае браузера прийдется висеть постоянно на связи

неправда.
это определяется вовсе не браузером.

← →
Alexandr © (2005-12-06 15:01) [24]

:) да не...
я все понимаю, только мысли плохо выражаю.
Я знаю что не браузером определяется, а тем, что в браузере крутится.

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

таблица да, тоже несовсем корректно. Скажем так "большого количества данных". (таких которые в куку не влезут).

← →
Плохиш © (2005-12-06 15:06) [25]

> (таких которые в куку не влезут).

Умные слова пошли.
Осталось выяснить связь между "большого количества данных" и Cookie.

← →
Digitman © (2005-12-06 15:12) [26]

> Alexandr © (06.12.05 15:01) [24]

> все понимаю, только мысли плохо выражаю

Значит есть повод для стремления к совершенству в их изложении, согласись ?

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

> таких которые в куку не влезут

не вижу повода хранить НД в куках ...

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

← →
Alexandr © (2005-12-06 15:16) [27]

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

← →
Digitman © (2005-12-06 15:27) [28]

> очень крутой вебсервер, который может вернуть такой скрипт.

вэб-серверу по барабану что возвращать .. он вернет любой скрипт, сформированный ТОБОЙ

но нужен вебсервер.
В этом то и проблема.
Так то запустил свое приложение и все.
А так, ставь апач, настраивай его.
Потом учи php, джаву, net, asp и прочие... Потом думай про овместимость с браузерами и т.п.

А тут, раздал программу, запустил AppServer и все. Проблем меньше.
Я думаю на эту программу потратить ну 3-7 дней. Не более того. И при этом не получить проблем потом на ровном месте.

Нет у меня опыта в web программировании.

> нужен вебсервер.
> В этом то и проблема

нет никакой проблемы.

тот же упомянутый Апач свободно скачивается с уймы ресурсов в сети, ибо он OpenSource-проект.

> Так то запустил свое приложение и все

ой ли ?

> А так, ставь апач, настраивай его

ну знаешь ли !

ставь ДОС и на сервер и на клиента - 6 секунд и никакого геморроя .. а так - ставь виндовину, да драйвера разные, да еще кучу хрени к ней непонятной, да админа потом нормального нанимай, чтобы он всю эту марахайку в работоспособом состоянии держал да юзеров неразумных пас ...

> Потом учи php, джаву, net, asp и прочие

неправда.

без действительной необходимости всю эту "php-джаву-net-asp"-байду учить не нужно.

> Нет у меня опыта в web программировании

а пора начинать

> А тут, раздал программу, запустил AppServer и все.

Я плякал

> Я думаю на эту программу потратить ну 3-7 дней. Не более
> того. И при этом не получить проблем потом на ровном месте.

Ты серьёзно думаешь, что тебе эту программу здесь напишут?

ладно. Будем сворачивать дискуссию.
Я для себя многое понял.

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

да не... дело не в этом.
Я то человек опытный.
А тут свалилась такая подзадача.
Вот и смотрю, как к ней быстрее подступиться, сделать и забыть.
Я отдаю себе отчет, что знаний у меня по этому вопросу нет, особенно подтвержденных практикой.
Но хотел сразу правильнй старт сделать.
А тут технологий то тьма...
и одна лучше другой, и выбрать без опыта непросто.
поэтому сделаю пилотный проект, посмотрю чего получится, потом думать буду с учетом результатов работы.
Уже решил пока использовать
IndyTCPClient и TCPserver и этот пример http://adg.bmpcoe.org/IndySSL/ за основу. А обработку текстов, которыми они обимениваться будут, я проще сам напишу. И все управляемо будет. Не такие там сложные команды. тут я умею более-менее.
Мне б только с каналом обмена разобраться.
Но пример работает как надо, и вроде тут все нормально.
А вникать глубоко пока нет ресурсов.

А вот тот же SOAP+SSL так оно медленно очень.

> IndyTCPClient и TCPserver

Это транпортный уровень.
С относительно небольшими прикладными надстройками.
Не более того.

Хочешь изобрести велосипед ? Дерзай.

Хочешь БЫСТРУЮ РАЗРАБОТКУ РАСПРЕДЕЛЕННОГО БИЗНЕС-ПРИЛОЖЕНИЯ ?

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

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

ошибаетесь.
Есть несколько разных процессов разработки ПО.

> Alexandr © (07.12.05 11:29) [38]
> ошибаетесь.
> Есть несколько разных процессов разработки ПО.

Можно список озвучить и указать те где думать не надо?

э...
с методологиями и этапами разработки ПО знаком?

так вот у меня сейчас стадия прототипа как раз. сделать быстро, если окажется полезно, то эту версию втопку, и писать заново уже правильно и с учетом результатов работы.
Если окажется, что оно и ненадо, то просто втопку и все.
примерно так. Например читать "Мифический человеко-месяц" по-моему.

выбор технологии для обмена данными Найти похожие ветки