On Wed, 29 Jul 2009, Francesco Saverio Giudice wrote:
Hi All,
>> The above is not true. This functions is implemented in the worst
>> possible way for performance. It calls recv() to extract single byte.
>> It means that the cost of switching between user and kernel space
>> is horrible huge and can kill the performance. I've seen how slow
>> it can be in some small programs written for pocket PC with WinCE.
>> The problem can be resolved by introducing internal buffer to
>> HB_SOCKET_STRUCT used by hb_inet*() functions and reading data in
>> bigger peaces. But it also means that we will have to update other
>> hb_inet*() functions to respect data in this buffer which can appear
>> after calling hb_InetRecvLine() or hb_InetRecvEndBlock() and I do
>> not know if I should invest time in cleaning this whole interface.
>> Maybe we should think about writing new one from scratch using
>> new hb_socket*() C functions?
>> How many people use current hb_inet*() functions and how important
>> is backward compatibility for you?
> I'm using hb_inet*() but I prefer to have new ones if give better
> functionalities and performance.
So we have two things: TIP library which uses hb_inet*() functions and
existing user code. So I suggest to make modifications in few steps.
I'll update current hb_inet*() interface and sync documentation with
existing code. I'll also add buffered reading for hb_inetRecvLine()
and hb_inetRecvEndBlock(). It's probably redundant work but it should
reduce possible mistakes in switching to new API.
I would like to ask here other developers which used hb_inet*() functions
and TIP library to carefully check existing TIP code end update it to
work correctly with hb_inet*() functions synced with documentations.
I'm not very familiar with TIP code but some user messages I've seen
suggested that some things do not work correctly, i.e. as workaround
for some problems with FTP TIP client Miguel introduced new functions
hb_inet[SG]et{Rcv,Snd}BufSize() and used them in HBTIP code.
To clarify: there is no even single technical reason to modify internal
IP buffer size in such context so above modifications should never appear
in core code (BTW in xHarbour above modifications seriously broke INET
code and it's broken so far though users are sending self contain examples
to xHarbour news group). Anyhow Miguel added such functionality (probably
without understanding what it exactly does) so I guess it helped him to
hide real bugs in some other code which we should find and fix because
above workaround is not real fix so the problem can appear with some
other conditions. Probably recent message from Jaroslaw Kadziola:
,-------------------------------------------------------------------------
| The same code to download 4 files is correct for WinXP but compiled and
| running on Windows Mobile one time correctly download all 4 files but
| second time 1 or 2 or 3 files have size 0 kb. Any tip ?
`-------------------------------------------------------------------------
is releated to this problem.
Can you and other TIP users help in cleaning TIP library code and verifying
if all hb_inet*() functions are used as in documentation?
If yes then I'll make modifications in hb_inet*() functions sync them
with documentation and add support for read ahead buffer.
Then later in some spare time I'll create new socket .prg API without
time deadline and I won't have to worry about even basic compatibility
to existing HB_INET*() API.
But before I'll change anything in existing HB_INET*() code I would like
to confirm that current implementation which uses internally hb_socket*()
C functions works like the old one. Have you made some tests with your code
and SVN after:
2009-07-29 11:53 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
