| skaller 2007-04-27, 1:17 am |
| On Tue, 24 Apr 2007 08:43:35 +0000, Andrei Voropaev wrote:
> On 2007-04-22, skaller <skaller@users.sf.net> wrote:
> [...]
>
> It can't be. I've never seen such a behaviour? The buffer is discarded
> only if the other side has sent RST. In all other cases, the data
> will be sent first and only then the FIN will be sent.
This is what I expected but not what I observed.
In my code I changed between setting and not setting
the O_NONBLOCK flag and the client read all the data
when it was clear, and failed to read all the data
when it was set.
This was observed using Firefox and wget as the clients.
Approximately 60K of data is lost in non-blocking mode:
which is roughly the buffer size Linux uses internally
isn't it?
The file being sent is 2.8Meg, the application buffer size
is currently 100K.
On smaller files there is no observed problem using a local connection.
For a 1500b/s ADSL connection to a remote server, it failed on every file
sent.
The 5 second delay fixes it .. there's not much
doubt that the buffers are not being written by the OS.
>
> You're just doing something wrong, when you have to use tricks with
> time-outs.
I hope you are correct. But I can't think what I could
possibly be doing wrong .. how can i get
close(fd);
wrong?? 
There is one remote possibility: the close is being
done in the middle of the transmission: they're done
in different pthreads. However debugging output
suggests this isn't the case: all the output is
written by the server code before the close is issued
by the other thread (the interlocking is fundamental
to the Felix system design so it had better work!)
More precisely, send() function completes with non-blocking
socket before close is issued, and there are mutexen
(plural of mutex .. in between to synchronise the two threads.
In the code epoll, poll, kqueue, select, Solaris
iocompletion ports or Windows iocompletion ports are used
to trigger writing in a dedicated event manager thread.
Close isn't done by this thread .. but it is done in
code that 'blocks' until the last send() returns.
> Or the peer of your application does something wrong.
Since I am using Firefox and wget as the clients I hope
that isn't the case.
> The example code would definetely help to tell where the things go
> wrong.
That is hard to show because it is part of a system of
libraries written in both C++ and in Felix.
if you REALLY want to look, the library code is all online:
http://felix.sourceforge.net/doc/en_flx_doc_0001.html
and you need to at least browse these entries:
Demux library (interscript): rtl/flx_demux/en_flx_demux_top.html
Felix async I/O library (interscript): rtl/flx_faio/en_flx_faio_top.html
or
Run time library (Doxygen): rtl/doxygen/html/index.html
if you prefer doxygen.
however the actual webserver code isn't online ..
but then it is written in Felix (which generates C++) so it isn't
clear it would be that useful.
>BTW. Why do you use "shutdown"?
Originally I didn't. However without it the client
seemed to hang about waiting for data, and closing
the socket at the server end caused Firefox to
display 'Reset whilst loading file' page, and wget
to abort and retry the fetch.
The HTTP service is deliberately dumb: it doesn't
support keep-alive or send the file size to the
client: the server is basically just a test and
demonstration of the system's asynchronous I/O capabilities.
[For fast output, there's no way to know the size of
a generated page anyhow: you'd have to cache the whole
page to find out]
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
|