developer toolbox » harbour

Nije zgoreg ponoviti:

NETIO works with all core RDDs (DBF, DBFFPT, DBFBLOB, DBFNTX, DBFCDX, DBFNSX, SDF, DELIM) and any other RDD which inherits from above or use standard RDD IO API (hb_file*() functions).

Without touching even single line in RDD code it gives the same functionality as REDBFCDX in xHarbour but for all RDDs.

It's possible that such direct TCP/IP connection is faster then file server protocols especially if they need more then one IP frame to exchange data so it's one of the reason to use it in such cases.

The second reason to use NETIO server is resolving problem with concurrent access to the same files using Harbour applications compiled for different platforms, i.e. DOS, LINUX, Windows and OS2.

It's very hard to configure all client stations to use correct locking system.

NETIO fully resolves this problem so it can be interesting alternative also for MS-Windows users only if they do not want to play with oplocks setting on each station.

Przemyslaw je glavni mozak harbour projekta.

Na listi su uslijedili komentari

Angel Pais:

Really fantastic !!!
Third reason to use NETIO: you don't have to share your dbf's folder, so nobody can open your dbfs with excel or other program than yours.

Big security improvement !

Hehe nismo samo mi koji imaju problema što im sa excelom uništavaju dbf fajlove

Konverzacija Pritipal - Przemek

> > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12382&view=rev
> > Author:   druzus
> > Date:     2009-08-31 22:56:45 +0000 (Mon, 31 Aug 2009)
> >
> First, thanks for this wonderful development.

Thank you to all of you for kind words.

> I am compiling netiotst.prg as
> hbmk2 netiotst.hbm -run
> and I receive this console output:
> NETIO_CONNECT(): .F.
> and then:
>   Error DBFCDX/1004  Create error:
>  net:127.0.0.1:2941:data/_tst_.dbf
>      Quit    Retry    Default
>
> This error is obivious as TCP/IP connection is not established.
> I think I am missing something but what ?
> Is it something connected with firewall or what ?

1-st: please check if you do not have firewall installed which may blocks access to given ports.
NETIO server uses port 2941 on and client code uses 'lo' interface (127.0.0.1) to access the server.
2-nd: please try to increase timeout after server starting and 1-st
connection. Now we have:
   hb_idleSleep( 0.1 )
but it's possible that on some OS-es it have to be bigger value, i.e.
use 1 or 2 seconds. I was testing it in my Linux box also with MinGW
builds using WINE and 0.1 sec. was enough but maybe in real Windows
the situation is different. Sorry but I was two lazy to eliminate this
race condition from netiotst code. Anyhow if longer time resolves the
problem for you then I'll update it.

E sad vezano za gornji komentar, LETODB je pretpostavljam klasični client server pristup, a ovo je client/server samo djelimično na nivou file access protokola.

Przemek pominje i NETRDD protokol. On je to par puta pominjao i radi se o njegovom client/server rješenju koje nikada nije objavio.

Ovo je vjerovatno subset tog rješenja (ili nije, ko zna ?) koji je koliko sam upratio reakcija na REDBFCDX koji je prije mjesec dva izazvao dosta diskusije na harbour listama.

Pod 1 radi se o zatvorenom rješenju, a pod 2 Przemek je rekao developerima da to nisu dobro uradili i da je njihovo rješenje praktično "hack".

Genijalac se naljutio i publikovao NETIO RDD.

multiple servers¶

On Tue, 01 Sep 2009, Horodyski Marek (PZUZ) wrote:

How we can connect to many than one server ?

In few different ways, i.e.:

NETIO_CONNECT( "192.168.0.1" )
   use net:table1
   NETIO_CONNECT( "192.168.0.2" )
   use net:table2
   use net:192.168.0.3:table3

NETIO_CONNECT() stores information about default connection in thread local area so can be safely used in MT programs. But you can also
use server name and port in file name.

You have this information in ChangeLog message I sent.

LETODB or NETIO ?¶

Subject: LETODB or NETIO ?
Sent By Ernad Husremovic On: September 1, 2009 10:31 AM
To: Harbour Project Main Developer List.

Hello hb community.
A few days ago, we started porting our clipper solutions to LETODB RDD.

Today I read about new Przemek great contribution: NETIO RDD.

Reading Changelog, NETIO is also good candidate for our default RDD.

Our main goal is to provide multiplatform (linux, windows) solution which is not vulnerable
to data corruption caused by direct file access.

In some earlier conversation, Przemek wrote:
> BTW it's not exactly client/server solution like in ADS or NETRDD if I finish it.

I would like to hear community comments about the optimal choice of (opensource) RDDs in the client/server arena.

Thank you,
Ernad

przemekov odgovor je bio da je letodb loše napisan i da se po njemu on teško može održavati ... tačnije po njemu bi to najbolje bilo napisati ispočetka

[Harbour] HBNETIO - Production Application Usage Pon 21 Sep 2009 07:22:08

From:     bedipritpal@hotmail.com
To:     harbour@harbour-project.org
Reply To:     harbour@harbour-project.org
Sender:     harbour-bounces@harbour-project.org

Hello Everybody

Here is what I did to test my flagship application "Vouch" 
under HBNETIO protocol concurrently with same system where
data resides, on LAN connected terminals with/without NETIO,
on real-time WEB-IP, and everything worked extremely fine.
The only issue worth reporting is the speed on WEB-IP
whic was 8 times slower than stand-alone and about
5 times slower than LAN.

ULTIMATELY - results were so satisfying that my clients
were noticeably impressed. And the credit goes to, PRZEMEK.
Thanks, you did a splendid job.

For WEB-IP we tested with this scenario:

1. Forwarded a port, #63000, on our wireless router.
2. Obtained a domain, vouch.dynalias.com, from DynDNS.com
3. Updated its IP with our server's IP.
4. Executed netiosrv.exe with  63000  192.168.1.108  c:\creative.v15
5. From the terminals invoked "Vouch.exe" with parameters
"vouch.dynalias.com" and "63000" through Vouch.ini.
6. Executed "Vouch.exe" as regular application as before from other
terminals and from same server station.

VOILA all went fine. One terminal employed was from out of the country.

All data updates, concurrent, were ok. All locks respected.

A big leap forward.

Regards
Pritpal Bedi

NETIO RPC filter¶

Re: [Harbour] hbnetio / rpc filter Sri 13 Jan 2010 06:59:16

From:     druzus@acn.waw.pl
To:     harbour@harbour-project.org
Reply To:     harbour@harbour-project.org
Sender:     harbour-bounces@harbour-project.org
On Tue, 12 Jan 2010, Szak�ts Viktor wrote:

Hi,

> I went along implementing custom RPC filters (as .hrb
> modules) in hbnetiosrv, but I realized half-way that
> I totally misunderstood current implementation.
>
> I was under the impression that NETIO_RPCFUNC() is a server
> side feature (since it's implemented in netiosrv.c), but
> as far as I could derive from source and tests, it's
> a client-side one.

No, it's not client side function.
It's server side function only and it cannot work on client side.

> The idea is that I'm creating a server .exe (hbnetiosrv)
> with all functions linked in (like hbrun) and I load
> a filter .hrb which will process all incoming RPC requests
> and either answer them or deny them.

So you have to write your own version of NETIO_MTSERVER() or
change NETIO_MTSERVER() parameters and pass function symbol
to your RPC filter.

> This would ensure that only controlled set of functions
> are executed on server and it also makes it possible to
> use one generic hbnetiosrv executable to serve different
> apps with different needs by loading server-side
> functionality with: hbnetiosrv -rpc=mysrvmodul.hrb
>
> Is this possible to do, or am I missing something in
> my observations here?

Yes it's possible anyhow you may want to implement your own
custom version of NETIO_MTSERVER() function in hbnetiosrv.prg
or extend parameter list used by this function to pass such
filter, i.e. as 5-th parameter.
Below I'm attaching three functions which you can add to your
hbnetiosrv. They implement RPC filer.
BTW please remember that this functionality will be extended
yet and I add also support for using hash array as RPC wrapper.
See my and Mindaugas messages about it.

> [ Doing filtering on the client side looks like a very
> risky solution, since by getting hold of connection
> parameters (ip+port+pw), anyone can write an app to do
> anything on the server. ]

It's not risk but idiotic idea and believe me that I will
never try to implement anything like that :-)

best regards,
Przemek

http://gitorious.bring.out.ba/harbour/harbour/blobs/master/harbour/contrib/hbnetio/netiomt.prg#line60

STATIC FUNCTION NETIO_MTSERVER( nPort, cIfAddr, cRootDir, lRPC, ... )
   LOCAL pListenSocket

   IF hb_mtvm()
      pListenSocket := netio_listen( nPort, cIfAddr, cRootDir, lRPC )
      IF !Empty( pListenSocket )
         hb_threadDetach( hb_threadStart( @netio_srvloop(), pListenSocket, ... ) )
      ENDIF
   ENDIF
   RETURN pListenSocket

STATIC FUNCTION NETIO_SRVLOOP( pListenSocket, ... )
   LOCAL pConnectionSocket

   WHILE .T.
      pConnectionSocket := netio_accept( pListenSocket,, ... )
      IF Empty( pConnectionSocket )
         EXIT
      ENDIF
      NETIO_RPCFUNC( pConnectionSocket, @MYRPC_FILTER() )
      hb_threadDetach( hb_threadStart( @netio_server(), pConnectionSocket ) )
      pConnectionSocket := NIL
   ENDDO
   RETURN NIL

STATIC FUNCTION MYRPC_FILTER( sFuncSym, ... )
   STATIC s_hLegal := { "DATE"=>, "TIME"=> }
   IF  sFuncSym:name $ s_hLegal
      RETURN sFuncSym:exec( ... )
   ENDIF
   RETURN "<<unsupported function>>" 

čovječe ... Viktor je upitao na temu rpc filtera i za jedan dan je osvanula nova verzija sa podrškom rpc-u

netio test 02

server

klijent

pozv klijenta

bringout@bringout-developer-amd64:~/devel/harbour-labs/netio$ ./tst_2

CONNECTING...                                                                                                                             
NETIO_CONNECT(): .T.

DATE() function is supported: .T.
QOUT() function is supported: .T.
HB_DATETIME() function is supported: .T.

SERVER DATE: 2010.01.13
SERVER TIME: 14:06:53  
SERVER DATETIME: 2010.01.13 14:06:53.261
HELLO WORLD !!!                         
    .  .   00:00:00.000
      1000             
NIL       
         0

NETIO_DISCONNECT(): .T.

bringout@bringout-developer-amd64:~/devel/harbour-labs/netio$ ./srv

NETIO server activated.                                                                                                                   

NETIO_CONNECT(): .T.

Directory './data' exists
kreiran je data dir cekam dalje instrukcije
Press any key to continue...               
======================================================================
This is RPC TEST 01/13/10 13:59:34.832 Harbour 2.0.1dev (Rev. -1)     
======================================================================
kreiram net:127.0.0.1:2941:topsecret:data/_tst_                       
create neterr: .F.          0                  
use neterr: .F.          0   

zapujem

ukratko na serveru sam napravio par db funkcija koje pozivam sa klijenta ... i to fakat radi.

idemo na NETIO nema dileme.

Re: [Harbour] Re: HBNETIO Sri 13 Jan 2010 20:13:47

From:     druzus@acn.waw.pl
To:     harbour@harbour-project.org
Reply To:     harbour@harbour-project.org
Sender:     harbour-bounces@harbour-project.org
On Wed, 13 Jan 2010, Angel Pais wrote:

Hi,

> >I like to take a try , to HBNETIO  using a little aplicattion made in XHgtk
> >but my network ( linux server ) is sharing databases using Samba and
> >I need to this work Correctly
> Been there, done that.
> On that scenario DON'T run netio server from same machine.
> Wine-Samba on same machine does ugly things when locking dbfs.
> A linux NetIO server uses a diferentent locking scheme.
> You need to compile netio server in windows to share dbfs with windows apps.
> Is not a defect from NetIO but a consecuence of mixing
> cliente-server with local acces and on top of that windows with
> linux.

Samba configuration is not related to HBNETIO.

HBNETIO does not change locking scheme or anything like that.
It redirects everything to OS. The main idea of using HBNETIO
is eliminating problems with file sharing using servers like
SAMBA. Just simply access file only using HBNETIO (it doesn't
matter what is the client OS) or native applications executed
locally and you will not have any problems with incompatible
locking systems.
Anyhow if you plan to also access simultaneously files using
SAMBA as file server then you have to configure *SAMBA to redirect
all locks to OS and fully respect all OS locking*. You will also
have to disable any opportunistic locks in SAMBA. The redirection
of SMB locks to OS lock in SAMBA was changing in the last years
and many problems has been resolved. Some of them using new
kernel extensions so it's also very important the system used
on file server running SAMBA. I cannot answer if current state
is fully functional and safe to use in concurrent file access
by SMB protocol and as native files without checking current
SAMBA code. I'll try to check it in some spare time. Anyhow
it always needs precise configuration so the easiest solution
for concurrent file access by remote stations is using HBNETIO
and ignoring any file servers like SAMBA or MARS.

best regards,
Przemek