On Fri, 30 Apr 2010, Mindaugas Kavaliauskas wrote: Hi,
> In case of item stream, received items are buffered on client side > and NETIO_GETDATA() return array of items. In case of char stream, > data is concatenated and NETIO_GETDATA() return a single stream. > Function NETIO_GETDATA() is not blocking function and returns NIL if > no data are received. Am I right? Yes you area. > You've mentioned in the past, that these communication streams > allows server application to give access to local resources like COM > ports, etc. In most cases, f.e. COM port, communication is > bidirectional, but I found communication stream unidirectional (from > server to client). How do you suggest to do data transfer in the > opposite direction? Just use standard RPC calls to set COM port parameters and send data and communication streams to receive incoming data. The streams are unidirectional only because standard RPC allows to send data from client to server. > In the sample code, the communication streams are closed after > NETIO_DISCONNECT(). Is data transfer allowed in between of > NETIO_DISCONNECT() and NETIO_CLOSESTREAM() calls? Each NETIO_CONNECT() increase reference counter in given connection and needs corresponding number of NETIO_DISCONNECT(). Each file open as "net:*" also increase the reference counter which is decreased when file is closed. Opening 1-st stream connection increase the reference counter too and it's decreased when all streams in given connection are closed. The order of executed command is unimportant here. The connection is closed when the reference counter reach 0. > Are connection stream ids unique among multiple connection? As far > as I can see, each connection has it's own connection ideas, and > this requires to use additional cServer and nPort parameters to > distinguish different connections. NETIO tries to reuse existing connection looking in open connections for the connection which has the same server and port number and if such connection exists then it's used and reference counter is increased. Otherwise new connection is created. > I see s_fileGetConnParam(), hb_socketResolveAddr(), s_fileConFind() > in NETIO_GETDATA(). Isn't this a bottleneck for applications what > needs a lot of data transfers? The same question for RPC calls. Probably only hb_socketResolveAddr() may cause noticeable speed overhead and here it's really better to use IP addresses to not activate DNS connection. Probably I should eliminate it adding support for pointer item with connection reference which can be used as 1-st parameter of RPC calls and connection streams. I'll think about it. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
