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@iem.at a écrit :
Quoting Claude Heiland-Allen claudiusmaximus@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