Отправлено: 03.05.13 15:52. Заголовок: NETIO

А не подскажет кто ,как повесить netio_mtserver в виде сервиса и как правильно
собрать задачу.
Есть необходимость удаленно делать архивацию дабы сетку не грузить.
Спасибо.

 Отправлено: 22.01.16 17:05. Заголовок: У кого то получилось..

У кого то получилось запустить NETIO (сервер) по порту отличному от 2941 ?

 Отправлено: 12.12.16 00:15. Заголовок: Можно ли получить кл..

Можно ли получить клиентские станции (client) которые работают с сервером NETIO ?
Интересует имя машины и IP адрес.
Можно конечно сделать через журнал-базу, но вдруг клиент отвалился по ошибке и запись за собой не подтер.

 Отправлено: 26.04.24 21:11. Заголовок: Прошу подсказать, чт..

Прошу подсказать, что можно передать в 4-м параметре NET_RPC mt-серверу
кроме логических .t. и .f.

В HBNETIO Documentation от Przemyslaw Czerpak <druzus / at / priv.onet.pl>
дано такое определение

NETIO_MTSERVER( [<nPort>], [<cIfAddr>], [<cRootDir>],
[<lRPC> | <sFuncSym> | <hValue>],
[<cPasswd>], [<nCompressionLevel>], [<nStrategy>] )
-> <pListenSocket>

Пробовал <lRPC> - то есть .t. или .f. - полное разрешение или запрет RPC-функций выполняется без проблем.

А, что надо вставлять вместо <sFuncSym>, чтобы ограничить список этих функций не понял.

Пробовал просто название функции - не вызывается. Массив из названий тоже не вышло.

Что понимается под <hValue> nоже непонятно ?

Если можно - пример типа "делай как я"

 Отправлено: 27.04.24 00:33. Заголовок: Возможно, <sFun..

Возможно, <sFuncSym> это ссылка на функцию, напрмер: @str() или @abs()

а <hValue> - число указатель на нее.

Тогда вопрос в другом - как ее вызывать из клиента через NETIO_FUNCEXEC()
?

 Отправлено: 27.04.24 18:50. Заголовок: subbota пишет: напр..

subbota пишет:

цитата:

напрмер: @str() или @abs()

что бы вызывать ту или иную функцию в исходнике сервера нужно их указать
типа так
request hb_curdrive
request curdir
request hb_zipfile
request ferase
request directory
request __copyfile
request hb_fcopy
request os
request hb_fileexists
request hb_DynCall
request hb_DirScan
и пересобрать его
в клиенте вызов типа netio_funcexec( "hb_fcopy".....и тд

 Отправлено: 27.04.24 21:39. Заголовок: Вопрос не в том, что..

Вопрос не в том, что некоторые функции не видны.
Их доступность действительно можно добавить через пересборку с request.

Если в 4-м параметре будет .t. - клиент плучает доступ ко всем ф-циям видимым серверу.
Есть множество ф-ций, видимых и без request. В том числе ф-ции основного модуля сервера.

А если в 4-м параметре будет .f. - клиенту запрещен доступ ко всем RPC функциям.

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

Аналогичный параметр имееет функция дополнительного фильтра
который можно наложить на сокет уже после запуска сервера.

NETIO_RPCFILTER( <pConnectionSocket>,
<sFuncSym> | <hValue> | NIL ) -> NIL

Что нужно записать при ее вызове вместо <sFuncSym> ?

 Отправлено: 29.04.24 02:17. Заголовок: Разобрался с параметром 4 для NETIO_MTSERVER( )

subbota пишет:

цитата:

В HBNETIO Documentation от Przemyslaw Czerpak <druzus / at / priv.onet.pl> дано такое определение NETIO_MTSERVER( [<nPort>], [<cIfAddr>], [<cRootDir>], [<lRPC> | <sFuncSym> | <hValue>], [<cPasswd>], [<nCompressionLevel>], [<nStrategy>] ) -> <pListenSocket> Пробовал <lRPC> - то есть .t. или .f. - полное разрешение или запрет RPC-функций выполняется без проблем. А, что надо вставлять вместо <sFuncSym>, чтобы ограничить список этих функций не понял.

Немного разобрался. Поясняю как понял сам.

RPC - это функции/процедуры, которые может вызывать клиент для их исполнения на сервере.
Если в 4-м параметре будет .t. - для клиента будут доступны все функции, видимые серверу.
Если в 4-м параметре будет .f. - клиенту будет запрещен доступ ко всем RPC функциям.

Если в 4-м параметре будет указатель на некоторую функцию, видимую на сервере,
то, при вызове клиентом любой RPC-функции, вместо нее сервер всегда выполнит
функцию, указатель которой был передан в 4-м параметре NETIO_MTSERVER()
и при этом передаст ей:
- в первом параметре указатель на RPC функцию, которую хочет вызвать клиент
- в следующих параметрах - значения для параметров вызываемой RPC функции.

Как я сделал
Добавил в prg-шник в модуле сервера ( того где вызов NETIO_MTSERVER() ) свою функцию примерно так:

function my_Func_Eval_RPC( s_RPC_func, xPar1, xPar2 ... )
...
local cName_RPC_func := hb_ValToStr( s_RPC_func ) // Так получу <@имя_RPC_функции()>, запрашиваемой клиентом
...
В xPar1, xPar2, ... - будут параметры для запрошенной RPC-функции
Текстовые выражения для параметров можно найти так:
private cxPar1 := hb_ValToStr( xPar1 )
private cxPar2 := hb_ValToStr( xPar2 )
...
Проанализировав: cName_RPC_func, cxPar1 и cxPar2,
можно решить, что сделать с этим запросом и что вернуть клиенту.

Например, так можно вернуть то, что он просит:
return s_RPC_func:exec( xPar1, xPar2 )

Или передать этот запрос куда-то еще, например, внешнему обработчику
и вернуть ему то, что вернет этот обработчик.

Запись вызова mt-сервера в модуле сервера для моего примера станет какой-то такой

pListenSocket := NETIO_MTSERVER( [<nPort>], [<cIfAddr>], [<cRootDir>], @my_Func_Eval_RPC(), [<cPasswd>], [<nCompressionLevel>], [<nStrategy>] )

Если клиент просит сервера выполнить hb_fsize( "myfile.dbf" ),
то вызов RPC - функции у клиента может быть таким:
NETIO_FUNCEXEC( "hb_fsize", "myfile.dbf" )

Тут только нужно не забыть, что полный путь к файлу на стороне сервера будет
cRootDir + "myfile.dbf"

Остальное в Readme.txt к Netio от Przemyslaw Czerpak <druzus / at / priv.onet.pl>

Я это описание и пример батовских файлов для консольной компиляции нашел в
Harbour MiniGUI Extended Edition 22.12 (Release)
MiniGUI\SAMPLES\Advanced\NETIO_1\

А идеалогия взаимодействия клиента и сервера Netio лучше понимается через
MiniGUI\SAMPLES\Advanced\NETIO_3\
Там же батники для графической компиляции.

Спасибо Dima за уделенное внимание !