[PD] dumpOSC problems "couldn't create"
reduzierer at yahoo.de
Mon Jul 21 17:39:44 CEST 2008
On Mon, 2008-07-21 at 17:27 +0200, Jack wrote:
> OK, i will try 'killall pd' next time.
> Thanx Hans.
> Le 20 juil. 08 Ã 19:13, Hans-Christoph Steiner a Ã©crit :
> > On Jul 19, 2008, at 7:24 PM, Jack wrote:
> >> Le 19 juil. 08 Ã 17:25, zmoelnig at iem.at a Ã©crit :
> >>> Quoting Claude Heiland-Allen <claudiusmaximus at goto10.org>:
> >>>> [dumpOSC 5555] needs to be able to bind to network port 5555, if
> >>>> something else is already using it (or if the previous user of the
> >>>> port
> >>>> hasn't timed out completely) then dumpOSC will fail to create.
> >>> which btw, is by design and not a bug.
> >>> it is the very same behaviour as the [netreceive] object has.
> >> This is a real problem with [netreceive]. For example when Pd crash,
> >> if you open your last patch, Pd can't create your [netreceive] with
> >> the same port. Is it possible to force to close connection on this
> >> port to solve the problem ?
> > Try running 'killall pd' to make sure there isn't a hung pd process
> > still running. Otherwise, you have to wait for the OS to free the
> > network port. That's not a pd-specific problem, but network
> > sockets in general.
this doesn't work on linux, afaik. from what i understood from people
from #debian channel, the problem is, that if clients don't say 'good
bye' in tcp protocol properly, the kernel keeps this specific port
occupied for a certain amount of time. afaik, this time can be adjust by
the sysctl, but unfortunately i can't recall anymore which. tcp_*time*
or tcp_*wait* or something like this.
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
More information about the Pd-list