On Tue, 01 Sep 2009, Pritpal Bedi wrote:

Hi Pritpal,

Thank you very much for your tests.

> For the deeper insight what you can use to 
> create test environments...
> 10.0.40.111 is a symbolic name, use your own.
> netserver.prg  
> ==========
> 0. Place netserver.exe on 10.0.40.111 in, say, mydata folder
> 1. Create a subfolder /data and stay in {mydata}
> 2. execute: {10.0.40.111/mydata/netserver.exe 63000 10.0.40.111 
> 3. Do not use 127.0.0.1 as it does not work : theoretically  it should.
> proc main( cPort, cServer ) 
>    local pListenSocket 
> 
>    if empty( cPort )
>       cPort := '63000'
>    endif
>    if empty( cServer )
>       cServer := '127.0.0.1'
>    endif
>    pListenSocket := netio_mtserver( val( cPort ), cServer ) 
>    if empty( pListenSocket ) 
>       ? "Cannot start server." 
>    else 
>       wait "Press any key to stop NETIO server." 
>       netio_serverstop( pListenSocket ) 
>       pListenSocket := NIL 
>    endif 
>    return 

Passing inet address to netio_mtserver() is only to select interfaces.
If you do not want to block access from different networks simply pass
nothing or "0.0.0.0" which has the same effect.

> netapplctn.prg   
> ===========
> 1. Stay anywhere you want on another terminal
> 2. execute:\>netappln.exe 10.0.40.111 63000
> #define DBNAME    "net:data/_tst_"
> request DBFCDX
> 
> proc main( cServer, cPort )
>    local pSockSrv
> 
>    set exclusive off
>    rddSetDefault( "DBFCDX" )
> 
>    if empty( cServer )
>       cServer := '127.0.0.1'
>    endif
>    if empty( cPort )
>       cPort := '63000'
>    endif
> 
>    ?
>    ? "NETIO_CONNECT():", cServer, int( val( cPort ) ), netio_connect(
> cServer, int( val( cPort ) ) )
>    ?
> 
>    createdb( DBNAME )
>    testdb( DBNAME )
>    wait
> 
>    return
> 
> proc createdb( cName )
>    local n
> if !dbExists( DBNAME )
>    dbCreate( cName, {{"F1", "C", 20, 0},;
>                      {"F2", "M",  4, 0},;
>                      {"F3", "N", 10, 2},;
>                      {"F4", "T",  8, 0}} )
>    ? "create neterr:", neterr(), hb_osError()
>    use (cName)
>    ? "use neterr:", neterr(), hb_osError()
>    while lastrec() < 100
>       dbAppend()
>       n := recno() - 1
>       field->F1 := chr( n % 26 + asc( "A" ) ) + " " + time()
>       field->F2 := field->F1
>       field->F3 := n / 100
>       field->F4 := hb_dateTime()
>    enddo
>    index on field->F1 tag T1
>    index on field->F3 tag T3
>    index on field->F4 tag T4
>    close
>    ?
> else
>    ? DBNAME, 'Already exists'
> endif
> return
> 
> proc testdb( cName )
>    local i, j
>    ?
>    ? 'using:',time()
>    use (cName)
>    ? "used:", time(), used()
>    ? "nterr:", neterr()
>    ? "alias:", alias()
>    ? "lastrec:", lastrec()
>    ? "ordCount:", ordCount()
>    for i:=1 to ordCount()
>       ordSetFocus( i )
>       ? i, "name:", ordName(), "key:", ordKey(), "keycount:", ordKeyCount()
>    next
>    ordSetFocus( 1 )
>    dbgotop()
>    while !eof()
>       if ! field->F1 == field->F2
>          ? "error at record:", recno()
>          ? "  ! '" + field->F1 + "' == '" + field->F2 + "'"
>       endif
>       dbSkip()
>    enddo
>    i := row()
>    j := col()
>    dbgotop()
> 
>    ? 'locking:',time()
>    ? 'locked:', rlock(), time()
> 
>    wait
> 
>    browse()
>    setpos( i, j )
>    close
> 
>    return
> 
> THE OBSERVATION
> ==============
> 1. USE command takes about 18 seconds to open a table

This is not inside Harbour code. At least not directly.
It should open table immediately just like any other operations.
If it's slower then for some reasons opening new connection is
delayed but it's outside of harbour application so should be
configurable by some system settings. Maybe it's side effect of
used firewall which tries to verify all accepted connections.
It's also possible that it's inside winsock library when name is
resolved. This you can easy verify by modifying netiocli.c[373].
Simply replace:
   pszIpAddres = hb_socketResolveAddr( pszServer, HB_SOCKET_AF_INET );
with:
   pszIpAddres = hb_strdup( pszServer );
recompile hbnetio library and your application and check if delay
in use still exists. If it resolves the problem then I would like
to know your C compiler so I can try to look for workaround but
it's hbsocket code problem not hbnetio.

> 2. Once table is opened, data access is quiet fast - almost instant
> 3. Locks are very well synchonized.
> 4. Data population is instantly visible on other terminals.

It should be. All accessed files are redirected to the server so
it should work without any problem. This is probably safer then using
SMB as transport layer because you do not have to worry about oplocks
setting or similar problems.

> 10.0.40.111 is a Windows 2003 Server on our local network.
> I could not test on some domain server which in fact be a real test.

Thank you for your tests.

best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to