Do you have a good description of the problem with [netserver]? If
so, I could take stab at it.
.hc
On Apr 26, 2009, at 8:27 PM, Roman Haefeli wrote:
hi martin, hi all
i ve been testing the new netpd-server based on the new
[tcpserver]/[tcsocketserver FUDI] now for a while and definitely could
solve some problems, but some new ones were introduced.
i found, that the most recent version of [tcpserver] peforms quite bad
cpu-wise. this has some side-effects. in netpd, when a certain
number of
users are logged in (let's say 16), it can happen, that the traffic of
those clients makes the netpd-server use more than the available
cpu-time. i made some tests and checked, if all messages come through
and if messages delivered by the server are still intact. under normal
circumstances, there is no problem at all. but under heavy load, when
the pd process is demanding more than available cpu time, some
messages
are corrupted or lost completely; in the worst case the pd process
segfaults, at the moment of a client connecting or disconnecting. i
guess, this is due to some buffer under- or overrun between pd and the
tcp stack, but i don't really know.
i wrote a benchmark patch and found out, that not only the new
netpd-server patch performs badly, but quite some portion of bad
performance comes from the new [tcpserver]. the testpatch compares
perfomances of sending data to clients using [tcpserver] and
[netserver]
from maxlib. the version of [tcpserver] shipped with current pd-
extended
performs slightly better than [netserver] (tested on OS X and linux).
however, the most recent version, that solves the tcp buffer overrun
problem, performs ~11 times worse than [netserver]. is that the trade
off from solving the other issue? or could this theoretically be
improved?
unfortunately, i still don't have a netpd-server running, which can be
considered stable. the current one doesn't crash anymore, because
clients lost network connection, but it crashes, when there is too
much
traffic. respectively, it cannot be considered reliable, because it
drops messages under certain circumstances.
@code-maintainers
is anyone maintaining the code of [netserver] or maxlib in general?
this
object class still suffers from the 'buffer overrun -> pd hangs'
problem. since the same problem was fixed for [tcpserver], it might
not
be too hard to port that fix to [netserver]. i am not able to dig
into c
sources, so i wanted to kindly ask here, if someone is interested to
do
it.
[tcpsocketserver FUDI] was meant as a replacement for [netserver] in
order to get rid of the pd hangs caused by it. however, now i am not
sure anymore, if this approach was a good idea at all, since the
overhead from implementing FUDI parsing and stuff in pd instead of
in c
seems to be enormeous.
roman
<
benchmark_server
.pd
>
<
benchmark_server_testclient
.pd>_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Access to computers should be unlimited and total. - the hacker ethic
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
