Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
On Thu, 07 Jan 2010, Szak�ts Viktor wrote: Hi, > We have hb_secondsCPU() in core, maybe code below could be > incorporated into it. It's not exactly the same. If possible (supported bu OS) hb_secondsCPU() returns number CPU cycles consumed by programs not real time clock. It means that d = hb_secondsCPU(); Sleep( 10 ); d = hb_secondsCPU() - d; should give value close to 0.0 because inside Sleep( 10 ) process is suspended by OS and do not consume CPU at all. I think that we should add new function to extract real time clock with high precision. Because precision can be different on different OS-es then we will have to chose holder which allow to set different precision. We can use 2 integer numbers for that or single double number (floating point number are internally divided to mantissa and exponent what gives us the functionality we are looking for) Mindaugas used double value in his example and it's reasonable for me. The return value from such function can be used only to measure some real time differences because in portable programs it's undefined, i.e. in Mindaugas'es code it's the time of 1-st call to this function. I'll add such function ASAP. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
We have hb_secondsCPU() in core, maybe code below could be
incorporated into it.
Brgds,
Viktor
On 2010 Jan 7, at 16:56, Mindaugas Kavaliauskas wrote:
> Hi,
>
> Mindaugas Kavaliauskas wrote:
>>> BTW how expensive (time consuming) is WINSOCK initialization in MS-Windows?
>> HB_ULONG ulTime = hb_dateMilliSeconds();
>> hb_socketInit();
>> HB_TRACE( HB_TR_ALWAYS, ("hb_socketInit() time=%d",
>> hb_dateMilliSeconds() - ulTime) );
>> prints:
>> netiocli.c:470: HB_TR_ALWAYS hb_socketInit() time=0
>> Do you have any other test code for it?
>
> Some time ago I was testing Python, Ruby, Java, etc speed. I was surprised
> about how Python's clock() function. It returns a lot of decimals on Windows.
> I've looked into the source and found a useful Win32 API function
> QueryPerformanceCounter for implementation of a high precision timer in
> Windows.
>
> Here is the simplest version:
> #include "windows.h"
> static LARGE_INTEGER iStart;
> static LARGE_INTEGER iFreq = {0};
> double hpclock( void )
> {
> LARGE_INTEGER iTime;
> if( iFreq.QuadPart == 0 )
> {
>QueryPerformanceCounter( &iStart );
>QueryPerformanceFrequency( &iFreq );
> }
> QueryPerformanceCounter( &iTime );
> return ( double )( iTime.QuadPart - iStart.QuadPart ) / ( double )
> iFreq.QuadPart;
> }
>
> The modified s_netio_init() code:
> double dTime = hpclock();
> hb_socketInit();
> HB_TRACE( HB_TR_ALWAYS, ("hb_socketInit() time=%g", hpclock() - dTime) );
> dTime = hpclock();
> Sleep(1000);
> HB_TRACE( HB_TR_ALWAYS, ("1 second =%g", hpclock() - dTime) );
> HB_TRACE( HB_TR_ALWAYS, ("hpclock() overhead=%g", hpclock() - hpclock())
> );
>
> prints:
>
> C:\harbour\contrib\hbnetio\tests>rpctest.exe
> netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00185554
> netiocli.c:492: HB_TR_ALWAYS 1 second =1.1
> netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.67619e-06
>
> .T.
> C:\harbour\contrib\hbnetio\tests>rpctest.exe
> netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00119596
> netiocli.c:492: HB_TR_ALWAYS 1 second =0.999618
> netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.67619e-06
>
> .T.
> C:\harbour\contrib\hbnetio\tests>rpctest.exe
> netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00146946
> netiocli.c:492: HB_TR_ALWAYS 1 second =0.999511
> netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.39683e-06
>
> .T.
> C:\harbour\contrib\hbnetio\tests>rpctest.exe
> netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00144739
> netiocli.c:492: HB_TR_ALWAYS 1 second =0.999809
> netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.67619e-06
>
> .T.
> C:\harbour\contrib\hbnetio\tests>rpctest.exe
> netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00116998
> netiocli.c:492: HB_TR_ALWAYS 1 second =0.999526
> netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.67619e-06
>
> .T.
> C:\harbour\contrib\hbnetio\tests>rpctest.exe
> netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00183431
> netiocli.c:492: HB_TR_ALWAYS 1 second =0.99934
> netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.39683e-06
>
> .T.
> C:\harbour\contrib\hbnetio\tests>rpctest.exe
> netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00191924
> netiocli.c:492: HB_TR_ALWAYS 1 second =0.99944
> netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.95556e-06
>
> .T.
> C:\harbour\contrib\hbnetio\tests>rpctest.exe
> netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00148734
> netiocli.c:492: HB_TR_ALWAYS 1 second =0.999669
> netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.67619e-06
>
> .T.
>
> We already have two time functions that return seconds from midnight and
> milliseconds (absolute UTC), but sometimes it is useful to have a higher
> precision time function and a function that "ignores" adjustment of computer
> time. The proposed function has these properties, but I do not know if such
> implementation is possible in another platforms. I guess this clock uses CPU
> clock counter, so, I do not know how it works in real multi-CPU environment.
>
>
> Regards,
> Mindaugas
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
Hi,
Mindaugas Kavaliauskas wrote:
BTW how expensive (time consuming) is WINSOCK initialization in
MS-Windows?
HB_ULONG ulTime = hb_dateMilliSeconds();
hb_socketInit();
HB_TRACE( HB_TR_ALWAYS, ("hb_socketInit() time=%d",
hb_dateMilliSeconds() - ulTime) );
prints:
netiocli.c:470: HB_TR_ALWAYS hb_socketInit() time=0
Do you have any other test code for it?
Some time ago I was testing Python, Ruby, Java, etc speed. I was
surprised about how Python's clock() function. It returns a lot of
decimals on Windows. I've looked into the source and found a useful
Win32 API function QueryPerformanceCounter for implementation of a high
precision timer in Windows.
Here is the simplest version:
#include "windows.h"
static LARGE_INTEGER iStart;
static LARGE_INTEGER iFreq = {0};
double hpclock( void )
{
LARGE_INTEGER iTime;
if( iFreq.QuadPart == 0 )
{
QueryPerformanceCounter( &iStart );
QueryPerformanceFrequency( &iFreq );
}
QueryPerformanceCounter( &iTime );
return ( double )( iTime.QuadPart - iStart.QuadPart ) / ( double )
iFreq.QuadPart;
}
The modified s_netio_init() code:
double dTime = hpclock();
hb_socketInit();
HB_TRACE( HB_TR_ALWAYS, ("hb_socketInit() time=%g", hpclock() -
dTime) );
dTime = hpclock();
Sleep(1000);
HB_TRACE( HB_TR_ALWAYS, ("1 second =%g", hpclock() - dTime) );
HB_TRACE( HB_TR_ALWAYS, ("hpclock() overhead=%g", hpclock() -
hpclock()) );
prints:
C:\harbour\contrib\hbnetio\tests>rpctest.exe
netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00185554
netiocli.c:492: HB_TR_ALWAYS 1 second =1.1
netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.67619e-06
.T.
C:\harbour\contrib\hbnetio\tests>rpctest.exe
netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00119596
netiocli.c:492: HB_TR_ALWAYS 1 second =0.999618
netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.67619e-06
.T.
C:\harbour\contrib\hbnetio\tests>rpctest.exe
netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00146946
netiocli.c:492: HB_TR_ALWAYS 1 second =0.999511
netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.39683e-06
.T.
C:\harbour\contrib\hbnetio\tests>rpctest.exe
netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00144739
netiocli.c:492: HB_TR_ALWAYS 1 second =0.999809
netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.67619e-06
.T.
C:\harbour\contrib\hbnetio\tests>rpctest.exe
netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00116998
netiocli.c:492: HB_TR_ALWAYS 1 second =0.999526
netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.67619e-06
.T.
C:\harbour\contrib\hbnetio\tests>rpctest.exe
netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00183431
netiocli.c:492: HB_TR_ALWAYS 1 second =0.99934
netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.39683e-06
.T.
C:\harbour\contrib\hbnetio\tests>rpctest.exe
netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00191924
netiocli.c:492: HB_TR_ALWAYS 1 second =0.99944
netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.95556e-06
.T.
C:\harbour\contrib\hbnetio\tests>rpctest.exe
netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00148734
netiocli.c:492: HB_TR_ALWAYS 1 second =0.999669
netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.67619e-06
.T.
We already have two time functions that return seconds from midnight and
milliseconds (absolute UTC), but sometimes it is useful to have a higher
precision time function and a function that "ignores" adjustment of
computer time. The proposed function has these properties, but I do not
know if such implementation is possible in another platforms. I guess
this clock uses CPU clock counter, so, I do not know how it works in
real multi-CPU environment.
Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
Hi,
Przemysław Czerpak wrote:
Ups. Sorry I forgot that automatic initialization is not enabled by
default. In netiocli.c it's covered by:
#if defined( HB_NETIO_STARTUP_INIT )
[...]
#endif
Yes :) By adding a few more tracelog, I've also found this reason :)
So it's expected and probably also startup winsock initialization works.
If possible please check it by adding ' || 1 ' to above #if condition
and replacing:
hb_vmAtInit( s_netio_init, NULL );
with:
s_netio_init( NULL );
Both ways works OK.
BTW how expensive (time consuming) is WINSOCK initialization in MS-Windows?
HB_ULONG ulTime = hb_dateMilliSeconds();
hb_socketInit();
HB_TRACE( HB_TR_ALWAYS, ("hb_socketInit() time=%d",
hb_dateMilliSeconds() - ulTime) );
prints:
netiocli.c:470: HB_TR_ALWAYS hb_socketInit() time=0
Do you have any other test code for it?
Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
On Thu, 07 Jan 2010, Mindaugas Kavaliauskas wrote:
Hi,
> >If possible please verify if this code:
> > PROC main()
> > ? NETIO_PROCEXISTS("127.0.0.1:2941:STR")
> > RETURN
> >works after above modification. I cannot test it in Linux because
> >in WINE WINSOCK initialization is not necessary.
> It still does not work...
Ups. Sorry I forgot that automatic initialization is not enabled by
default. In netiocli.c it's covered by:
#if defined( HB_NETIO_STARTUP_INIT )
[...]
#endif
So it's expected and probably also startup winsock initialization works.
If possible please check it by adding ' || 1 ' to above #if condition
and replacing:
hb_vmAtInit( s_netio_init, NULL );
with:
s_netio_init( NULL );
BTW how expensive (time consuming) is WINSOCK initialization in MS-Windows?
> BTW:
> ../../../netiocli.c:
> Warning W8004 ../../../netiocli.c 502: 'size' is assigned a value
> that is never used in function s_netio_params
Thanks for the info. I'll clean it on next commit.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
Hi,
Przemysław Czerpak wrote:
2010-01-07 14:14 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/contrib/hbnetio/netiocli.c
! use hb_vmAtInit() to initialize NETIO - looks that winsock
initialization in startup code does not work - please test
If possible please verify if this code:
PROC main()
? NETIO_PROCEXISTS("127.0.0.1:2941:STR")
RETURN
works after above modification. I cannot test it in Linux because
in WINE WINSOCK initialization is not necessary.
It still does not work... I've put some debug code:
conn = s_fileConnect( &pszProcName, NULL, 0, 0 ); in s_netio_procexec()
returns NULL.
sd = hb_socketOpen( HB_SOCKET_PF_INET, HB_SOCKET_PT_STREAM, 0 ); in
s_fileConnect() returns -1.
BTW:
../../../netiocli.c:
Warning W8004 ../../../netiocli.c 502: 'size' is assigned a value that
is never used in function s_n
etio_params
Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
On Thu, 07 Jan 2010, Mindaugas Kavaliauskas wrote:
Hi,
> Przemysław Czerpak wrote:
> > PROC main()
> > HB_INETINIT()
> > ? NETIO_PROCEXISTS("127.0.0.1:2941:STR")
> > RETURN
> >but it's possible that when it's executed as startup code then
> >such initialization do not work and we should use hb_vmAtInit()
> >function. Can you verify it?
> You are right. HB_INETINIT() solves the problem.
Thank you for the information. I've just committed:
2010-01-07 14:14 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/contrib/hbnetio/netiocli.c
! use hb_vmAtInit() to initialize NETIO - looks that winsock
initialization in startup code does not work - please test
If possible please verify if this code:
PROC main()
? NETIO_PROCEXISTS("127.0.0.1:2941:STR")
RETURN
works after above modification. I cannot test it in Linux because
in WINE WINSOCK initialization is not necessary.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
Hi,
Przemysław Czerpak wrote:
PROC main()
HB_INETINIT()
? NETIO_PROCEXISTS("127.0.0.1:2941:STR")
RETURN
but it's possible that when it's executed as startup code then
such initialization do not work and we should use hb_vmAtInit()
function. Can you verify it?
You are right. HB_INETINIT() solves the problem.
Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
Very good news! can we plan & promote a 2.1 with GTnet and hbide is some month? 2010/1/7 Przemysław Czerpak : > On Wed, 06 Jan 2010, Pritpal Bedi wrote: > > Hi, > >> I can sense this commit is the basis for NETRDD or NETGT of future. >> Am I right ? > > It can be useful for both but in fact it's side effect of some other > job not directly related to Harbour. > Anyhow I plan to work on GTNET in the nearest future so above code > should greatly help. > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
Hi Przemysław Czerpak wrote: > > Anyhow I plan to work on GTNET in the nearest future so above code > should greatly help. > I could not hear a better with than above few words, for 2010. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13489--trunk-harbour-tp27046268p27055841.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
On Wed, 06 Jan 2010, Pritpal Bedi wrote: Hi, > I can sense this commit is the basis for NETRDD or NETGT of future. > Am I right ? It can be useful for both but in fact it's side effect of some other job not directly related to Harbour. Anyhow I plan to work on GTNET in the nearest future so above code should greatly help. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
On Thu, 07 Jan 2010, Mindaugas Kavaliauskas wrote:
Hi,
> PROC main()
> ? netio_connect()
> ? NETIO_PROCEXISTS("STR")
> RETURN
> prints:
> .T.
> .T.
> but
> PROC main()
> ? NETIO_PROCEXISTS("127.0.0.1:2941:STR")
> RETURN
> prints:
> .F.
> What I'm missing?
It's working for me in my Linux box so I can only guess that it's a
problem with socket initialization in windows builds. Please try:
PROC main()
HB_INETINIT()
? NETIO_PROCEXISTS("127.0.0.1:2941:STR")
RETURN
We have in netiocli.c:
HB_CALL_ON_STARTUP_BEGIN( _hb_file_netio_init_ )
s_netio_init();
HB_CALL_ON_STARTUP_END( _hb_file_netio_init_ )
but it's possible that when it's executed as startup code then
such initialization do not work and we should use hb_vmAtInit()
function. Can you verify it?
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
On Thu, 07 Jan 2010, Mindaugas Kavaliauskas wrote:
Hi,
> Mindaugas Kavaliauskas wrote:
> >homework.prg (test module):
> >PROC main()
> > ? netio_connect()
> > ? NETIO_PROCEXISTS("HB_HRBLOAD")
> > ? NETIO_PROCEXISTS("HELLO")
> > ? NETIO_PROCEXECW("HB_HRBLOAD", HB_MEMOREAD("homework2.prg"))
> > ? NETIO_PROCEXISTS("HELLO")
> > ? NETIO_FUNCEXEC("HELLO")
> >RETURN
> >Unfortunately test code prints:
> >.T.
> >.T.
> >.F.
> >and application hangs up.
> Sorry. It was a simple typo, should be:
>? NETIO_PROCEXECW("HB_HRBLOAD", HB_MEMOREAD("homework1.hrb"))
> This method works!
Yes and it's _exactly_ what I have in mind though I haven't thought
about using #pragma __streaminclude. Very nice solution.
Thank you very much.
It also shows what clever programmer can do if he knows well HVM
internals. It's enough to leave even small peace code and he can
make what he only wants and it's the reason why protection by
available function list can work only if this is rather short list
of small and simple functions well known that work without any side
effects.
> BTW, results for this test are:
[...]
> I.e. every second time existing function is destroyed by
> unsuccessful overload. I'm not sure (not tested the details) if it
> is a bug in runner.c or some strange side effect, like: the second
> time code s_hHrb := HB_HRBLOAD("...") is called, HB_HRBLOAD() fails
> because Hello() already exists.
It's not a bug. See include/hbhrb.ch.
HRB module was loaded with HB_HRB_BIND_DEFAULT what means:
/* do not overwrite any functions, ignore
public HRB functions if functions with
the same names already exist in HVM */
So when it's loaded second time public HELLO() function still exists
in HVM as part of previously loaded module and the new one is ignored.
Just after loading the new module you cleared s_hHrb so the old module
with HELLO() function was unloaded so all is correct.
> So, HB_HRBLOAD() returns empty value
> and destroys the last pointer to loaded hrb module in static
> variable. The next time module does not clashes with existing
> functions, so, it's loaded again.
> Modification of homework1.prg solves the problem:
> STATIC s_hHrb
> INIT PROC LoadHello()
> IF EMPTY(s_hHrb)
> #pragma __streaminclude "homework2.hrb"|s_hHrb := HB_HRBLOAD(%s)
> ENDIF
> RETURN
Yes it's enough. Other solution is clearing the old module before
registering the new one so its public functions will not be used,
i.e.:
STATIC s_hHrb
INIT PROC LoadHello()
s_hHrb := NIL // clear the old module
#pragma __streaminclude "homework2.hrb"|s_hHrb := HB_HRBLOAD(%s)
RETURN
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
Hello Przemek > Log Message: > --- > 2010-01-06 17:15 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/src/rtl/hbznet.c > ! do not use DEF_MEM_LEVEL to avoid potential problems when > is not available > > * harbour/contrib/hbnetio/netio.h > * harbour/contrib/hbnetio/netiocli.c > * harbour/contrib/hbnetio/netiosrv.c > + implemented RPC in HBNETIO protocol > Time and again you through bliss on us in terms of highly useful and advanced features, this is one in those gems, thank you very much. I can sense this commit is the basis for NETRDD or NETGT of future. Am I right ? Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13489--trunk-harbour-tp27046268p27055352.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
Hi,
Mindaugas Kavaliauskas wrote:
homework.prg (test module):
PROC main()
? netio_connect()
? NETIO_PROCEXISTS("HB_HRBLOAD")
? NETIO_PROCEXISTS("HELLO")
? NETIO_PROCEXECW("HB_HRBLOAD", HB_MEMOREAD("homework2.prg"))
? NETIO_PROCEXISTS("HELLO")
? NETIO_FUNCEXEC("HELLO")
RETURN
Unfortunately test code prints:
.T.
.T.
.F.
and application hangs up.
Sorry. It was a simple typo, should be:
? NETIO_PROCEXECW("HB_HRBLOAD", HB_MEMOREAD("homework1.hrb"))
^ ^^^
This method works!
BTW, results for this test are:
C:\harbour\contrib\hbnetio\tests>homework.exe
.T.
.T.
.F.
.T.
.T.
Hello, World! :)
C:\harbour\contrib\hbnetio\tests>homework.exe
.T.
.T.
.T.
.T.
.F.
NIL
C:\harbour\contrib\hbnetio\tests>homework.exe
.T.
.T.
.F.
.T.
.T.
Hello, World! :)
C:\harbour\contrib\hbnetio\tests>homework.exe
.T.
.T.
.T.
.T.
.F.
NIL
I.e. every second time existing function is destroyed by unsuccessful
overload. I'm not sure (not tested the details) if it is a bug in
runner.c or some strange side effect, like: the second time code s_hHrb
:= HB_HRBLOAD("...") is called, HB_HRBLOAD() fails because Hello()
already exists. So, HB_HRBLOAD() returns empty value and destroys the
last pointer to loaded hrb module in static variable. The next time
module does not clashes with existing functions, so, it's loaded again.
Modification of homework1.prg solves the problem:
STATIC s_hHrb
INIT PROC LoadHello()
IF EMPTY(s_hHrb)
#pragma __streaminclude "homework2.hrb"|s_hHrb := HB_HRBLOAD(%s)
ENDIF
RETURN
Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
Hi,
Przemysław Czerpak wrote:
On Wed, 06 Jan 2010, Lorenzo Fiorini wrote:
It's only important that the functions you want to execute are
linked with server code or where loaded dynamically. you can
even make sth like:
netio_procexec( "HB_HRBLOAD", hb_memoread( "mycode.hrb" ) )
BTW a small homework ;-) Test for HVM knowledge.
Find a method to register dynamically in HVM such function from
client side using NETIO server which is linked only with default
core functions without any custom extensions.
What does it mean "with default core functions"? Can I include
HB_HRBLOAD()? Or this should be done without uncommenting REQUEST
__HB_EXTERN__ in netiosrv.prg?
If linking of HB_HRBLOAD() is allowed, I propose solution:
homework2.prg (any functions to be registered):
FUNC Hello()
RETURN "Hello, World! :)"
homework1.prg (registrator module):
STATIC s_hHrb
INIT PROC LoadHello()
#pragma __streaminclude "homework2.hrb"|s_hHrb := HB_HRBLOAD(%s)
RETURN
homework.prg (test module):
PROC main()
? netio_connect()
? NETIO_PROCEXISTS("HB_HRBLOAD")
? NETIO_PROCEXISTS("HELLO")
? NETIO_PROCEXECW("HB_HRBLOAD", HB_MEMOREAD("homework2.prg"))
? NETIO_PROCEXISTS("HELLO")
? NETIO_FUNCEXEC("HELLO")
RETURN
Unfortunately test code prints:
.T.
.T.
.F.
and application hangs up. I can not force HB_HRBLOAD() to work on server
side, though:
? NETIO_FUNCEXEC("STR", 5.1, 7, 2)
prints the expected result.
Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
Hi,
All above functions use default connection set by NETIO_CONNECT()
for RPCs but it's also possible to specify server address and port
in / just like in parameter in RDD
functions, i.e.:
NETIO_PROCEXISTS( "192.168.0.1:10005:MYFUNC" )
PROC main()
? netio_connect()
? NETIO_PROCEXISTS("STR")
RETURN
prints:
.T.
.T.
but
PROC main()
? NETIO_PROCEXISTS("127.0.0.1:2941:STR")
RETURN
prints:
.F.
What I'm missing?
Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
> On Wed, 06 Jan 2010, Szak�ts Viktor wrote:
>> Too smoothen the security edge of this feature,
>> maybe it would be nice to allow to limit the set
>> of functions made available through RPC on the
>> server side. This way programmer could have total
>> control over this aspect without worrying about
>> function being linked without knowledge or intent,
>> and keep verifying .map files to find out.
>
> Any limits by function list are usually very easy to exploit.
> As long as you do not plan to give access to some very small
> set of functions then sooner or later hacker find a way to
> pass some string to macrocompiler and make what he only wants
> i.e. if you allow to execute ordListAdd() then he can create
> index file with key expression having functions you wanted to
> block, etc. Such things has to be resolved inside HVM. See
> information I left about it in xhb-diff.txt at the end of
> NAMESPACEs section.
> Now instead of implementing feature which gives rather illusion
> of security instead of real protection I suggest to add very
> simply extension. User function which can be registered in
> NETIO socket and executed instead of really requested functions
> so if user thinks that such list is enough for him then he can
> make sth like:
>
> static s_funcLst := { "STR"=>, "DATE"=>, "TIME"=> }
> func mywrapper( sFunc, ... )
> if sFunc:name $ s_funcLst
> return sFunc:exec( ... )
> endif
> return nil
Perfectly fits what I had in mind.
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
On Wed, 06 Jan 2010, Szak�ts Viktor wrote:
> Too smoothen the security edge of this feature,
> maybe it would be nice to allow to limit the set
> of functions made available through RPC on the
> server side. This way programmer could have total
> control over this aspect without worrying about
> function being linked without knowledge or intent,
> and keep verifying .map files to find out.
Any limits by function list are usually very easy to exploit.
As long as you do not plan to give access to some very small
set of functions then sooner or later hacker find a way to
pass some string to macrocompiler and make what he only wants
i.e. if you allow to execute ordListAdd() then he can create
index file with key expression having functions you wanted to
block, etc. Such things has to be resolved inside HVM. See
information I left about it in xhb-diff.txt at the end of
NAMESPACEs section.
Now instead of implementing feature which gives rather illusion
of security instead of real protection I suggest to add very
simply extension. User function which can be registered in
NETIO socket and executed instead of really requested functions
so if user thinks that such list is enough for him then he can
make sth like:
static s_funcLst := { "STR"=>, "DATE"=>, "TIME"=> }
func mywrapper( sFunc, ... )
if sFunc:name $ s_funcLst
return sFunc:exec( ... )
endif
return nil
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
On Wed, 06 Jan 2010, Lorenzo Fiorini wrote:
> > It's only important that the functions you want to execute are
> > linked with server code or where loaded dynamically. you can
> > even make sth like:
> > netio_procexec( "HB_HRBLOAD", hb_memoread( "mycode.hrb" ) )
> > result := netio_funcexec( "MYFUNC1", param1, param2, param3 )
> > ? netio_funcexec( "MYFUNC2", result )
> Do you mean that all the functions inside the "mycode.hrb" are
> automatically registered and available without defining them DYNAMIC?
Yes but not all function. Only public functions inside loaded .hrb
module will be available and static not. Anyhow I made mistake here.
In current code HRB modules are automatically unloaded if you do not
store return value with pointer to HRB module in some visible for HVM
variable. To eliminate this effect you can create your own procedure
like:
proc my_hrbLoad( cHrb )
static s_aHrbHandles := {}
aadd( s_aHrbHandles, hb_hrbLoad( cHrb ) )
return
and link it with the netio server.
BTW a small homework ;-) Test for HVM knowledge.
Find a method to register dynamically in HVM such function from
client side using NETIO server which is linked only with default
core functions without any custom extensions.
> I mean can it be a way to have dynamic non binary libs of functions?
Yes, you can load HRB modules or dynamic libraries which register new
functions and they will be available for RPC sever just like are available
for macro compiler.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
Great feature. Thanks a lot for it. Too smoothen the security edge of this feature, maybe it would be nice to allow to limit the set of functions made available through RPC on the server side. This way programmer could have total control over this aspect without worrying about function being linked without knowledge or intent, and keep verifying .map files to find out. Brgds, Viktor On 2010 Jan 6, at 17:16, dru...@users.sourceforge.net wrote: > Revision: 13489 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13489&view=rev > Author: druzus > Date: 2010-01-06 16:16:22 + (Wed, 06 Jan 2010) > > Log Message: > --- > 2010-01-06 17:15 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/src/rtl/hbznet.c >! do not use DEF_MEM_LEVEL to avoid potential problems when > is not available > > * harbour/contrib/hbnetio/netio.h > * harbour/contrib/hbnetio/netiocli.c > * harbour/contrib/hbnetio/netiosrv.c >+ implemented RPC in HBNETIO protocol >+ added the following client functions: > check if function/procedure exists on the server side: > NETIO_PROCEXISTS( ) -> > execute function/procedure on server the side, > do not wait for confirmation: > NETIO_PROCEXEC( [, ] ) -> > execute function/procedure on the server side and wait for > confirmation: > NETIO_PROCEXECW( [, ] ) -> > execute function on the server side and wait for its return value: > NETIO_FUNCEXEC( [, ] ) -> > All above functions use default connection set by NETIO_CONNECT() > for RPCs but it's also possible to specify server address and port > in / just like in parameter in RDD > functions, i.e.: > NETIO_PROCEXISTS( "192.168.0.1:10005:MYFUNC" ) >+ added new server side functions to enable/disable/check RPC support: > NETIO_RPC( | [, ] ) > -> > if RPC is enabled for listen socket then connection sockets inherit > this setting. >+ added 4-th parameter to NETIO_LISTEN() function. .T. enable > RPC support in returned listen socket which is later inherited by > connection sockets >* changed protocol version ID - current NETIO clients and servers > cannot be used with old code > > * harbour/contrib/hbnetio/utils/netiosrv.prg >* added option to enable RPC support in NETIO server > > If you want to make some test then you can execute netiosrv with > non empty 4-th parameter as server, i.e.: > ./netiosrv "" "" "" 1 > and try this code as client: > > proc main() > // pass server address to netio_connect() for non localhost tests > ? "NETIO_CONNECT():", netio_connect() > ? > ? "DATE() function is supported:", netio_procexists( "DATE" ) > ? "QOUT() function is supported:", netio_procexists( "DATE" ) > ? "HB_DATETIME() function is supported:", ; > netio_procexists( "HB_DATETIME" ) > ? > ? netio_procexec( "QOUT", repl( "=", 50 ) ) > ? netio_procexec( "QOUT", "This is RPC TEST", date(), hb_datetime() ) > ? netio_procexecw( "QOUT", repl( "=", 50 ) ) > ? > ? "SERVER DATE:", netio_funcexec( "DATE" ) > ? "SERVER TIME:", netio_funcexec( "TIME" ) > ? "SERVER DATETIME:", netio_funcexec( "HB_DATETIME" ) > ? > ? netio_funcexec( "upper", "hello world !!!" ) > return > > Please remember that only functions linked with server are available. > If you want to enabled all core functions in netiosrv then please > uncomment this line in netiosrv.prg: > REQUEST __HB_EXTERN__ > > > Have a fun with a new toy. I hope that many Harbour user will find it > very interesting. Please only be careful !!!. This feature allows to > execute remotely _ANY_ code on the server side. _NEVER_ leave open ports > with RPC support for untrusted access. > > Modified Paths: > -- >trunk/harbour/ChangeLog >trunk/harbour/contrib/hbnetio/netio.h >trunk/harbour/contrib/hbnetio/netiocli.c >trunk/harbour/contrib/hbnetio/netiosrv.c >trunk/harbour/contrib/hbnetio/utils/netiosrv.prg >trunk/harbour/src/rtl/hbznet.c > > > This was sent by the SourceForge.net collaborative development platform, the > world's largest Open Source development site. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
On Wed, Jan 6, 2010 at 5:16 PM, wrote: > * harbour/contrib/hbnetio/netio.h > * harbour/contrib/hbnetio/netiocli.c > * harbour/contrib/hbnetio/netiosrv.c > + implemented RPC in HBNETIO protocol > ... > Have a fun with a new toy. I hope that many Harbour user will find it > very interesting. Please only be careful !!!. This feature allows to > execute remotely _ANY_ code on the server side. _NEVER_ leave open ports > with RPC support for untrusted access. WOW this is a SUPER gift. Many thanks. Just a question. > Please remember that only functions linked with server are available. This is clear to me, but then you added: > It's only important that the functions you want to execute are > linked with server code or where loaded dynamically. you can > even make sth like: > netio_procexec( "HB_HRBLOAD", hb_memoread( "mycode.hrb" ) ) > result := netio_funcexec( "MYFUNC1", param1, param2, param3 ) > ? netio_funcexec( "MYFUNC2", result ) Do you mean that all the functions inside the "mycode.hrb" are automatically registered and available without defining them DYNAMIC? I mean can it be a way to have dynamic non binary libs of functions? best regards, Lorenzo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
On Wed, 06 Jan 2010, Massimo Belgrano wrote: Hi, > possible now create directories automatically if not there on the remote? Massimo, what is not clear in my ChangeLog entry? I even updated NETIO server example and added to ChangeLog demonstration code. Please don't be so fast and think a little bit before you ask about sth. Using RPC you can execute any function or procedure on the server side, MKDIR is not an exception here, i.e.: netio_procexec( "MKDIR", "C:\TEST" ) It's only important that the functions you want to execute are linked with server code or where loaded dynamically. you can even make sth like: netio_procexec( "HB_HRBLOAD", hb_memoread( "mycode.hrb" ) ) to register your .hrb file with set of your own functions on the server side and then execute them using: result := netio_funcexec( "MYFUNC1", param1, param2, param3 ) ? netio_funcexec( "MYFUNC2", result ) In summary you can do anything, also netio_procexec( "__run", "format D: /u/y" ) so please be extremely careful with this feature. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
possible now create directories automatically if not there on the remote? 2010/1/6 : > Revision: 13489 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13489&view=rev > Author: druzus > Date: 2010-01-06 16:16:22 + (Wed, 06 Jan 2010) > > Log Message: > --- > 2010-01-06 17:15 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/src/rtl/hbznet.c > ! do not use DEF_MEM_LEVEL to avoid potential problems when > is not available > > * harbour/contrib/hbnetio/netio.h > * harbour/contrib/hbnetio/netiocli.c > * harbour/contrib/hbnetio/netiosrv.c > + implemented RPC in HBNETIO protocol > + added the following client functions: > check if function/procedure exists on the server side: > NETIO_PROCEXISTS( ) -> > execute function/procedure on server the side, > do not wait for confirmation: > NETIO_PROCEXEC( [, ] ) -> > execute function/procedure on the server side and wait for > confirmation: > NETIO_PROCEXECW( [, ] ) -> > execute function on the server side and wait for its return value: > NETIO_FUNCEXEC( [, ] ) -> > All above functions use default connection set by NETIO_CONNECT() > for RPCs but it's also possible to specify server address and port > in / just like in parameter in RDD > functions, i.e.: > NETIO_PROCEXISTS( "192.168.0.1:10005:MYFUNC" ) > + added new server side functions to enable/disable/check RPC support: > NETIO_RPC( | [, ] ) > -> > if RPC is enabled for listen socket then connection sockets inherit > this setting. > + added 4-th parameter to NETIO_LISTEN() function. .T. enable > RPC support in returned listen socket which is later inherited by > connection sockets > * changed protocol version ID - current NETIO clients and servers > cannot be used with old code > > * harbour/contrib/hbnetio/utils/netiosrv.prg > * added option to enable RPC support in NETIO server > > If you want to make some test then you can execute netiosrv with > non empty 4-th parameter as server, i.e.: > ./netiosrv "" "" "" 1 > and try this code as client: > > proc main() > // pass server address to netio_connect() for non localhost tests > ? "NETIO_CONNECT():", netio_connect() > ? > ? "DATE() function is supported:", netio_procexists( "DATE" ) > ? "QOUT() function is supported:", netio_procexists( "DATE" ) > ? "HB_DATETIME() function is supported:", ; > netio_procexists( "HB_DATETIME" ) > ? > ? netio_procexec( "QOUT", repl( "=", 50 ) ) > ? netio_procexec( "QOUT", "This is RPC TEST", date(), hb_datetime() ) > ? netio_procexecw( "QOUT", repl( "=", 50 ) ) > ? > ? "SERVER DATE:", netio_funcexec( "DATE" ) > ? "SERVER TIME:", netio_funcexec( "TIME" ) > ? "SERVER DATETIME:", netio_funcexec( "HB_DATETIME" ) > ? > ? netio_funcexec( "upper", "hello world !!!" ) > return > > Please remember that only functions linked with server are available. > If you want to enabled all core functions in netiosrv then please > uncomment this line in netiosrv.prg: > REQUEST __HB_EXTERN__ > > > Have a fun with a new toy. I hope that many Harbour user will find it > very interesting. Please only be careful !!!. This feature allows to > execute remotely _ANY_ code on the server side. _NEVER_ leave open ports > with RPC support for untrusted access. > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
