[PD] dumpOSC problems "couldn't create"

[Roman Haefeli]

On Mon, 2008-07-21 at 17:27 +0200, Jack wrote:
> OK, i will try 'killall pd' next time.
> Thanx Hans.
> ++
> 
> Jack
> 
> 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.

roman 


	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de