System::OleVariant Packet;
Packet="TableName="+cdsTest->Name+"\nCommant=20\n";
...
Передача значений TClientDataSet через сокет. Как оптимальней?
Собственно по сабжу. Мне необходимо организовать обмен данными между TClientDataSet и TProvaider. Естественно не только передачу но и обработку передаваемых данных. Если кому приходилось решать схожее - меня собственно интересует следуещее -
как работать с System::OleVariant - как записать данные - ну вроде как понятно - а как мне считать данные - как получить содержащиеся пару-значение если мне в момент получения не известено кто отправил этот пакет. Я предполагаю следуещее:
Клиент посылает запрос серверу на передачу данных.
Если сервер откликнулся - посылается имя компонента, который инициирует передачу, и чего надо.
Получив подтверждение сервера начинается собственно передача.
На стороне клиента я записываю ключ-значение:
Дальше передаю их, на стороне сервера делаю парсинг. Мне кажется это громоздко. Может я чето не то делаю? У Датасета еть свойство DataRecquest - но я не могу разобраться как его использовать. Как мне определить из пакета - какой из компонентов чего хочет?
Чегото запутался. Вот собственно с вот этими моментами мне непонятно. Как в какой момент надо передавать данные компоненту и какое событие при этом надо использовать? И как получать данные из переданного.
как работать с System::OleVariant - как записать данные - ну вроде как понятно - а как мне считать данные - как получить содержащиеся пару-значение если мне в момент получения не известено кто отправил этот пакет. Я предполагаю следуещее:
Клиент посылает запрос серверу на передачу данных.
Если сервер откликнулся - посылается имя компонента, который инициирует передачу, и чего надо.
Получив подтверждение сервера начинается собственно передача.
На стороне клиента я записываю ключ-значение:
Код:
Дальше передаю их, на стороне сервера делаю парсинг. Мне кажется это громоздко. Может я чето не то делаю? У Датасета еть свойство DataRecquest - но я не могу разобраться как его использовать. Как мне определить из пакета - какой из компонентов чего хочет?
Чегото запутался. Вот собственно с вот этими моментами мне непонятно. Как в какой момент надо передавать данные компоненту и какое событие при этом надо использовать? И как получать данные из переданного.
Цитата:
Originally posted by kot_
Собственно по сабжу. Мне необходимо организовать обмен данными между TClientDataSet и TProvaider. Естественно не только передачу но и обработку передаваемых данных. Если кому приходилось решать схожее - меня собственно интересует следуещее -
как работать с System::OleVariant - как записать данные - ну вроде как понятно - а как мне считать данные - как получить содержащиеся пару-значение если мне в момент получения не известено кто отправил этот пакет. Я предполагаю следуещее:
Клиент посылает запрос серверу на передачу данных.
Если сервер откликнулся - посылается имя компонента, который инициирует передачу, и чего надо.
Получив подтверждение сервера начинается собственно передача.
На стороне клиента я записываю ключ-значение:
Дальше передаю их, на стороне сервера делаю парсинг. Мне кажется это громоздко. Может я чето не то делаю? У Датасета еть свойство DataRecquest - но я не могу разобраться как его использовать. Как мне определить из пакета - какой из компонентов чего хочет?
Чегото запутался. Вот собственно с вот этими моментами мне непонятно. Как в какой момент надо передавать данные компоненту и какое событие при этом надо использовать? И как получать данные из переданного.
Собственно по сабжу. Мне необходимо организовать обмен данными между TClientDataSet и TProvaider. Естественно не только передачу но и обработку передаваемых данных. Если кому приходилось решать схожее - меня собственно интересует следуещее -
как работать с System::OleVariant - как записать данные - ну вроде как понятно - а как мне считать данные - как получить содержащиеся пару-значение если мне в момент получения не известено кто отправил этот пакет. Я предполагаю следуещее:
Клиент посылает запрос серверу на передачу данных.
Если сервер откликнулся - посылается имя компонента, который инициирует передачу, и чего надо.
Получив подтверждение сервера начинается собственно передача.
На стороне клиента я записываю ключ-значение:
Код:
System::OleVariant Packet;
Packet="TableName="+cdsTest->Name+"\nCommant=20\n";
...
Packet="TableName="+cdsTest->Name+"\nCommant=20\n";
...
Дальше передаю их, на стороне сервера делаю парсинг. Мне кажется это громоздко. Может я чето не то делаю? У Датасета еть свойство DataRecquest - но я не могу разобраться как его использовать. Как мне определить из пакета - какой из компонентов чего хочет?
Чегото запутался. Вот собственно с вот этими моментами мне непонятно. Как в какой момент надо передавать данные компоненту и какое событие при этом надо использовать? И как получать данные из переданного.
Несовсем понял чего хочешь, но посмотри на связку: TClientDataSet::GetOptionalParam и TDataSetProvider::OnGetDataSetProperties.
Цитата:
Originally posted by GIZMO
Несовсем понял чего хочешь, но посмотри на связку: TClientDataSet::GetOptionalParam и TDataSetProvider::OnGetDataSetProperties.
Несовсем понял чего хочешь, но посмотри на связку: TClientDataSet::GetOptionalParam и TDataSetProvider::OnGetDataSetProperties.
Ну это первое на что я посмотрел. :)
Но до конца с этим я пока не разобрался - в частности, при попытке проработать пример из справки машина вошла в завис... вполне возможно я не не разобрался - что именно должна передавать эта функция.
Судя по всему эта связка как раз и необходима - фактически мне нужно написать аналог TSocketConnection - но без использования борландовского сокета и аналог РДМ с необходимой мне функциональностью.
Вобщем то в связи с чем возникла данная задача. Мне необходимо организовать работу с приложением-сервером с использованием ТСР/IP протокола. Задачи сервера - прием-рассылка пакетов, анализ входящей/исходящей информации, авторизация пользователей - гибкая(т.е. использоваться может авторизация в БД, в винде, может собственный механизм буде нужно будет), кодировка/раскодировка инфы передача в базу данных. Т.е. это тривиальный миддл-сервер.
В процессе разработки я столкнулся с рядом проблем - часть из которых связана с отсутствием опыта работы с СОМ-интерфейсами (из-за чего собственно вытекает глупейшие ошибки и промахи), а часть связанна с программными решениями борланда.
Понятно, что по первому вопросу выход один. Его еще дедушка Бланк(Ульянов)прописал - учится учится и набивать шишки :)
А вот по второму вопросу - некоторые вещи меня не устраивают собственно так как они реализованы в билдере.
1. Для работы с TSocketConnection необходимо запускать допПО. Если рабочих мест - 50 это не проблема. Если юзер зарубил процесс или какая ошибка - ну настроил заново и все проблемы. в доку прописал необходимость ну бывает. На 1000 рабочих мест с расстояниями между ними в сотни и десятки км - хм.... задача уже становится сложнее. Если при том по ряду причин не может использоватся удаленное админство - это уже становится весьма не тривиальной задачей.
2. Борланд сокет-сервер работает в режиме блокирующей передачи. Возможно это наиболее простое решение, возможно связано с работой с РДМ - я еще не разобрался - но факт остается. В результате - запрос данных иногда способен весьма ощутимо приостановить работу. Плюс к тому - не возможность (может не разобрался пока) организовать несколько потоков обращений к серверу. Т.е. один компонент в один момент времени. Не годится. При работе в сети - это еще терпимо - легко регулируется. При работе по жопорезу - это уже вполне серьезная проблема.
3. Это возможно опять же связано с проблемами моей квалификации - может просто не могу разобраться - но мне необходимо выполнять анализ даных до того как они попадут в базу. В провайдере вроде как чтото подобное предусмотрено - но пока как реализовать это для промышленной системы - я не разобрался.
4. Необходимость реализовывать механизм авторизации пользователей. Так как из возможных вариантов - управление средствами операционки - что вне домена достаточно сложно.
Ну вот примерно список проблем с которыми я столкнулся. Пытаясь решить их я использовал 3 варианта - первый это модель СОМ, второй CORBA и третий написание компонента-брокера для передачи данных(ну и соответтвенно для приема на другой стороне) на основе компонентов-сокетов.
Работа с СОМ мне в принципе не понравилась тем, что необходимо понижать уровень безопасности системы - в связи с удаленными юзерами - в принципе решение есть но здорово усложняющее всю и так не простую систему. Ну и работу по удаленному доступу трудно назвать стабильной. Хотя вроде пробовал и раздельную модель и свободную - ошибка в области доступа одного клиента - рушит весь сервер(я имею ввиду комовсий сервер). Понятно, что можно переподключится повторно - но уж слишком часто это происходило. Причем списать на мои ошибки сложно - так как я тестировал работу - из моего кода - только названия формы и компонента :)
СORBA - штука мощная - но на ее освоение нужно отчень не мало времени - дополнительно к тому - опять же наличие целой кучи дополнительного ПО причем весьма не стабильного (у меня ушло порядка 4 часов что бы настроить работу брокера на своей машине, а на сервере я потратил несколько дней и так и не смог запустить необходимые сервисы - проблема связана с джава-машиной). Вобщем пока фтопку - буду разбираться и осваивать, но программировать на этом - может позже.
Ну и третий вариант - то чем сейчас занимаюсь - рою исходники, мотрю как люди делают и делаю для своих задач. Во многом я повторю уже готовые решеня - немного корбы, немного ком - но с учетом своих а не глобальных задач :) Небольшой опыт разработки своего формата есть, но единственная проблема - совместить с датасетам его :)
Ну по ходу буду давать вести с фронтов :)
В процессе разработки я столкнулся с рядом проблем - часть из которых связана с отсутствием опыта работы с СОМ-интерфейсами (из-за чего собственно вытекает глупейшие ошибки и промахи), а часть связанна с программными решениями борланда.
Понятно, что по первому вопросу выход один. Его еще дедушка Бланк(Ульянов)прописал - учится учится и набивать шишки :)
А вот по второму вопросу - некоторые вещи меня не устраивают собственно так как они реализованы в билдере.
1. Для работы с TSocketConnection необходимо запускать допПО. Если рабочих мест - 50 это не проблема. Если юзер зарубил процесс или какая ошибка - ну настроил заново и все проблемы. в доку прописал необходимость ну бывает. На 1000 рабочих мест с расстояниями между ними в сотни и десятки км - хм.... задача уже становится сложнее. Если при том по ряду причин не может использоватся удаленное админство - это уже становится весьма не тривиальной задачей.
2. Борланд сокет-сервер работает в режиме блокирующей передачи. Возможно это наиболее простое решение, возможно связано с работой с РДМ - я еще не разобрался - но факт остается. В результате - запрос данных иногда способен весьма ощутимо приостановить работу. Плюс к тому - не возможность (может не разобрался пока) организовать несколько потоков обращений к серверу. Т.е. один компонент в один момент времени. Не годится. При работе в сети - это еще терпимо - легко регулируется. При работе по жопорезу - это уже вполне серьезная проблема.
3. Это возможно опять же связано с проблемами моей квалификации - может просто не могу разобраться - но мне необходимо выполнять анализ даных до того как они попадут в базу. В провайдере вроде как чтото подобное предусмотрено - но пока как реализовать это для промышленной системы - я не разобрался.
4. Необходимость реализовывать механизм авторизации пользователей. Так как из возможных вариантов - управление средствами операционки - что вне домена достаточно сложно.
Ну вот примерно список проблем с которыми я столкнулся. Пытаясь решить их я использовал 3 варианта - первый это модель СОМ, второй CORBA и третий написание компонента-брокера для передачи данных(ну и соответтвенно для приема на другой стороне) на основе компонентов-сокетов.
Работа с СОМ мне в принципе не понравилась тем, что необходимо понижать уровень безопасности системы - в связи с удаленными юзерами - в принципе решение есть но здорово усложняющее всю и так не простую систему. Ну и работу по удаленному доступу трудно назвать стабильной. Хотя вроде пробовал и раздельную модель и свободную - ошибка в области доступа одного клиента - рушит весь сервер(я имею ввиду комовсий сервер). Понятно, что можно переподключится повторно - но уж слишком часто это происходило. Причем списать на мои ошибки сложно - так как я тестировал работу - из моего кода - только названия формы и компонента :)
СORBA - штука мощная - но на ее освоение нужно отчень не мало времени - дополнительно к тому - опять же наличие целой кучи дополнительного ПО причем весьма не стабильного (у меня ушло порядка 4 часов что бы настроить работу брокера на своей машине, а на сервере я потратил несколько дней и так и не смог запустить необходимые сервисы - проблема связана с джава-машиной). Вобщем пока фтопку - буду разбираться и осваивать, но программировать на этом - может позже.
Ну и третий вариант - то чем сейчас занимаюсь - рою исходники, мотрю как люди делают и делаю для своих задач. Во многом я повторю уже готовые решеня - немного корбы, немного ком - но с учетом своих а не глобальных задач :) Небольшой опыт разработки своего формата есть, но единственная проблема - совместить с датасетам его :)
Ну по ходу буду давать вести с фронтов :)