Hi,
I'm experiencing some very odd thing. When I open my patch, with a dumpOSC and a OSCRoute, sometimes the dumpOSC box can't be created. As it's not allways I'm sure is not a path problems to the library. As I'm working in something that needs to be kind of stable, I'm getting a bit worried. Using the 39.3 version in a windows xp environment. Any ideas of why that happens or how to solve it?
Thanks so much for the help!
Maíra
Conheça o Windows Live Spaces, a rede de relacionamentos do Messenger! http://www.amigosdomessenger.com.br/
MaÃra Sala wrote:
Hi,
I'm experiencing some very odd thing. When I open my patch, with a dumpOSC and a OSCRoute, sometimes the dumpOSC box can't be created. As it's not allways I'm sure is not a path problems to the library. As I'm working in something that needs to be kind of stable, I'm getting a bit worried. Using the 39.3 version in a windows xp environment. Any ideas of why that happens or how to solve it?
[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.
Thanks so much for the help!
MaÃra
Conheça o Windows Live Spaces, a rede de relacionamentos do Messenger! http://www.amigosdomessenger.com.br/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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.
and before i forget it: have i already said that i would advice
everybody to _not_ use [dumpOSC] (as part of the OSCx library) and
instead use mrpeach's [udpreceive] and [unpackOSC]?
fadrm IOhannes
This message was sent using IMP, the Internet Messaging Program.
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 ?
++
Jack
and before i forget it: have i already said that i would advice everybody to _not_ use [dumpOSC] (as part of the OSCx library) and instead use mrpeach's [udpreceive] and [unpackOSC]?
fadrm IOhannes
This message was sent using IMP, the Internet Messaging Program.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
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.
.hc
++
Jack
and before i forget it: have i already said that i would advice everybody to _not_ use [dumpOSC] (as part of the OSCx library) and instead use mrpeach's [udpreceive] and [unpackOSC]?
fadrm IOhannes
This message was sent using IMP, the Internet Messaging Program.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism. - retired U.S. Army general, William Odom
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..hc
++
Jack
and before i forget it: have i already said that i would advice everybody to _not_ use [dumpOSC] (as part of the OSCx library) and instead use mrpeach's [udpreceive] and [unpackOSC]?
fadrm IOhannes
This message was sent using IMP, the Internet Messaging Program.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism. - retired U.S. Army general, William Odom
Jack wrote:
OK, i will try 'killall pd' next time.
this is likely to _not_ help (and probably worsen things), as it does a bad job in closing files and sockets (which is what you need here).
as root try to enable fast socket recycling with somehing like:
# echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
according to the docs: "It should not be changed without advice/request of technical experts." so i am neither a technical expert nor do i advice you to do so. but it is one thing that often helps me.
the other is, to not let Pd crash.
fga,sdr IOhannes
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
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 ? ++
http://lists.puredata.info/pipermail/pd-list/2007-06/050710.html
Jack
and before i forget it: have i already said that i would advice everybody to _not_ use [dumpOSC] (as part of the OSCx library) and instead use mrpeach's [udpreceive] and [unpackOSC]?
fadrm IOhannes
This message was sent using IMP, the Internet Messaging Program.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thanx for the link Claude.
It seems there is no way to force to close the connection (wait 10 mn
or reboot the computer or change the port), it's a pity.
++
Jack
Le 20 juil. 08 à 12:34, Claude Heiland-Allen a écrit :
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 ? ++http://lists.puredata.info/pipermail/pd-list/2007-06/050710.html
Jack
and before i forget it: have i already said that i would advice everybody to _not_ use [dumpOSC] (as part of the OSCx library) and instead use mrpeach's [udpreceive] and [unpackOSC]?
fadrm IOhannes
This message was sent using IMP, the Internet Messaging Program.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/
listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
-
Claude Heiland-Allen -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jack -
Maíra Sala -
Roman Haefeli -
zmoelnig＠iem.at