Соекты — это конечно хорошо. Но это всего лишь один из транспортов, причём самый низкоуровневый, как следствие — трудно программируемый и совершенно не решающий задачи обеспечения безопасности.
Более высокоуровневые механизмы сетевого общения между клиентом и сервером, доступные в C++: DCOM, SOAP, CORBA, RPC. Всё перечисленное — это уже не транспортные механизмы (протоколы), а стандарты удалённого взаимодействия (вызова порцедур). DCOM, SOAP, CORBA — объектно-ориенторованные (передача объектов по сети), RPC — remoute procedure call (гольный вызов удалённых процедур без всяких объектов).
DCOM реализован в самой винде, но требует множество плясок с бубном, чтобы защитить соединение и не открыть во внешнюю среду печально известный 135-ый порт — порще всего удалённые машины включать в свой домен по VPN, но зато если вы это сделаете, то считайте большая часть проблем с удалённой коммуникацией решена. В реализации операется на RPC. По сути DCOM — объектно-ориентированная обёртка над RPC.
CORBA — по сути аналог DCOM`а, но платформенно независимый. Плюсы — реализации есть и на Unix системах, и под Windows, и в Java. Минусы — с безопасностью там туговато. Как и DCOM реализована поверх RPC.
SOAP — потокол удалённого взаимодействия, основанный на передаче xml`я по HTTP соединению. Сервер по сути WEB-сервис слушающий входящие POST (GET) запросы. В оригинале не включает какие-либо средства обеспечения безопасноти, но есть различные промышленные стандарты и надстройки для этих целей, например, WSE 2.0. Правда SOAP проще использовать на из C++, а скажем, из C#.
RPC — удалённый вызов процедур, этим всё сказано. Реализация встроена практически в любую сетевую ОС. Есть и в Windows. Использовать сложно — сокеты проще .
Теперь немного насчёт ручной секьюрити, если всё таки захочешь сокеты или CORBA, или не найдёшь достойной реализации того же WSE 2.0 для плюсов.
SSPI — это специальная технология в Windows для выполнения авторизации, аутентификации и организации безопасного соединения через произвольный транспорт с помощью различных протоколов. Вещь неплохая, но самому разбираться в ней тяжеловато, хорошо была описана в книге Дж. Рихтера "Windows 2000. Разработка серверных приложений". Стандартная поставка серверной Windows включает SSPI провайдеров для NTLM, Kerberos и SSP (по сути HTTPS).
CryptoAPI — опять таки стандартная криптографическая библиотека Windows, включает рактически все аспекты современной криптографии, по крайней мере для шифрования и подписи точно хватит .
PKI — инфраструктура открытого ключа, в Windows реализована как составная часть CryptoAPI, но разобраться с тем, что это такое возможно придётся. Очень многие механизмы безопасности основаны именно на сертификатах. Провайдер SSP в SSPI — работает с сертификатами; SOAP, поскольку является по сути расширением HTTP тоже удобнее исползовать вместе с сертификатами (WSE включает такую возможность).
Ну вот... Что знал рассказал .
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[3]: Программные способы обмена информацией через интернет
Здравствуйте, realperfect, Вы писали:
R> Смысл не в том, чтобы в принципе решить данную задачу по автоматизации, а в том, чтобы сделать "всё своими руками", чтобы понять как это работает изнутри. А изучать принципы программирования на Java особого желания нет, больше тянет в область практического применения уже имеющихся знаний и навыков.
Кроме фиксации уже имеющихся навыков нужно еще выработать умение выбирать для задачи адекватный инструмент. Этому так же нужно учиться.
С нуля разрабатываю собственную клинет-серверную систему по автоматизации торговли, основная идея: в торговых точках стоят ПК с выходом в инет, на каждой сервер лок. БД по имеющемуся товару, учёт продаж ведётся с использованием штрих-кодов, информация по продажам в режиме он-лайн отсылается на домашний ПК собственника, где стоит центр. хранилище данных по всем отделам. В итоге собственник может удалённо вести аналитику продаж, устанавливать новые цены и ставить_на_приход/списывать новые поступления.
В качестве модели ведения учёта взята модель учёта торгового отдела в котором некогда я подрабатывал охранником (да, было и такое). Разработка интерфейсной части и функционала аналитики в принципе не представляет для меня неразрешимой задачи.
Проблема в реализации программного обмена информацией через интернет: между ПК торгового отдела и ПК собственника. В разработке использую язык Builder C++, подскажите, пожалуйста, какие имеются механизмы для решения моей задачи в контексте данного языка?
P.S. Если у кого есть какие замечания или предложения по поводу общей модели разрабатываемой системы, буду рад за оставленные вами комметарии.
P.S. Я не сумасшедший, а энтузиазма мне не занимать. Просто недавно закончил технический ВУЗ и хочется реального программирования! А на работе — только сплошная интеграция, да сопровождение.
Всем спасибо, жду ваших ответов.
Re: Программные способы обмена информацией через интернет
<...> R> P.S. Я не сумасшедший, а энтузиазма мне не занимать. Просто недавно закончил технический ВУЗ и хочется реального программирования! А на работе — только сплошная интеграция, да сопровождение.
После создания такой системы с нуля, в одиночку, на C++, вы напрочь отобъете себе охоту заниматься программированием.
Если уж очень хочется, то лучше посмотреть в сторону Java Enterprise Edition и существующих де-факто стандартов, вроде WebServices. Они специально для этих целей и создавались.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Программные способы обмена информацией через интернет
Здравствуйте, LuciferMoscow, Вы писали:
LM>Здравствуйте, realperfect, Вы писали: LM><skipped> LM>Например, сокеты. Если от удаленного компа нужна только БД, то методы безусловно должны быть другими
LM>Но сразу возникает вопрос нужна ли данная софтина на рынке? Упал интернет и магазин парализовало....
Согласен конечно, что интернет — такая штука, которая иногда недоступна, но сбои подобного рода как правило носят временный характер. И замечу, что идея состоит в том, чтобы в каждом торговом отделе стоит своя, лок. БД по имеющемуся товару (по товару, закреплённому за данным отделом), своего рода дубликат одного из разделов центр. хранилица данных.
В данном свете проблема временного сбоя соединения с интернетом решается сама собой: по восстановлении соединения не переданная информация об уже проданном товаре сразу же отсылается в центр. хранилище. Тем самым работа магазина не парализуется во время сбоя в сети, просто собственник некоторое время не может получить точной информации об объёмах продаж на настоящий момент.
А по поводу сокетов, не могли бы вы рассказать об этом поподробней. Принцип их использования, может есть какие стандартные библиотеки, в которых реализованы функции для работы с сокетами, если нет, то где можно найти детальное описание этой технологии?
P.S. В области сетевого программирования я пока ещё новичок..
Re[2]: Программные способы обмена информацией через интернет
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, realperfect
E><...> R>> P.S. Я не сумасшедший, а энтузиазма мне не занимать. Просто недавно закончил технический ВУЗ и хочется реального программирования! А на работе — только сплошная интеграция, да сопровождение.
E>После создания такой системы с нуля, в одиночку, на C++, вы напрочь отобъете себе охоту заниматься программированием.
E>Если уж очень хочется, то лучше посмотреть в сторону Java Enterprise Edition и существующих де-факто стандартов, вроде WebServices. Они специально для этих целей и создавались.
Смысл не в том, чтобы в принципе решить данную задачу по автоматизации, а в том, чтобы сделать "всё своими руками", чтобы понять как это работает изнутри. А изучать принципы программирования на Java особого желания нет, больше тянет в область практического применения уже имеющихся знаний и навыков.
Re: Программные способы обмена информацией через интернет
Здравствуйте, realperfect, Вы писали:
R> С нуля разрабатываю собственную клинет-серверную систему по автоматизации торговли,
Как уже тут сказали, задача не из простых, но если сильно хочется...
R>основная идея: в торговых точках стоят ПК с выходом в инет, на каждой сервер лок. БД по имеющемуся товару, учёт продаж ведётся с использованием штрих-кодов, информация по продажам в режиме он-лайн отсылается на домашний ПК собственника, где стоит центр. хранилище данных по всем отделам. В итоге собственник может удалённо вести аналитику продаж, устанавливать новые цены и ставить_на_приход/списывать новые поступления.
Тут какая-то нестыковочка получается. Каким образом клиенты будут коннектиться на домашний ПК собственника? Тут как вариант надо собственника тоже клиентом делать, а в локалке магазинной ставить сервак с белым IP, базой данных товаров, серверной программой, и кней коннектиться и с касс и с домашнего ПК.
Здравствуйте, realperfect, Вы писали:
R> Согласен конечно, что интернет — такая штука, которая иногда недоступна, но сбои подобного рода как правило носят временный характер. И замечу, что идея состоит в том, чтобы в каждом торговом отделе стоит своя, лок. БД по имеющемуся товару (по товару, закреплённому за данным отделом), своего рода дубликат одного из разделов центр. хранилица данных. R> В данном свете проблема временного сбоя соединения с интернетом решается сама собой: по восстановлении соединения не переданная информация об уже проданном товаре сразу же отсылается в центр. хранилище. Тем самым работа магазина не парализуется во время сбоя в сети, просто собственник некоторое время не может получить точной информации об объёмах продаж на настоящий момент.
Насчет временных сбоев это хорошо Иногда инет на пару дней ложится.
И решение задачи синхронизации БД после сбоя — очень веселая вещь.
R> А по поводу сокетов, не могли бы вы рассказать об этом поподробней. Принцип их использования, может есть какие стандартные библиотеки, в которых реализованы функции для работы с сокетами, если нет, то где можно найти детальное описание этой технологии? R> P.S. В области сетевого программирования я пока ещё новичок..
MSDN+пробуй написать клиент&сервер. Там почти ничего сложного. Конкретные вопросы задавай
.
Иногда инет на пару дней ложится.