hi list,
i have the problem that after a crash or just a reopen of a patch
with the netserver object (i believe netreceive will have the same
issue) i need to wait a couple of seconds up to a minute until pd
allows me to open the same patch with a successful creation of the
netserver object, because the port seems to be already (still) in use.
is there a way to force the port to reset or close? it's a little
annoying especially in live situations if everybody has to wait....
m..
Try this from the Terminal:
killall -KILL pd
.hc
On Jun 4, 2007, at 8:50 PM, Max Neupert wrote:
hi list,
i have the problem that after a crash or just a reopen of a patch with the netserver object (i believe netreceive will have the same issue) i need to wait a couple of seconds up to a minute until pd allows me to open the same patch with a successful creation of the netserver object, because the port seems to be already (still) in use.
is there a way to force the port to reset or close? it's a little annoying especially in live situations if everybody has to wait....
m..
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess
himself of it. - Thomas Jefferson
Hans-Christoph Steiner wrote:
Try this from the Terminal:
killall -KILL pd
in my experience this does not help with hung [netreceive] objects. even more, i sometimes do have no pd-process any more anyhow (because it was quitted) and still the port is blocked and therefore not [netreceive] can be created.
it would be interesting to know which process actually locks the port ("lsof -i" usually does not reveal anything in these cases). if nothing else helps, a reboot will do (rebooting might be faster than waiting a couple of minutes)
i don't know of any (pd-side) solution to this problem, that won't make things worse. one (probably not so good) idea would be to actually create the object and try to get the port in a background process. however, this will make things very hard to debug.
masd.r IOhannes
There's nothing you can do about a hung port short of rebooting the
machine. This has always been a problem with the netserver and
flashserver objects (maybe someone should look into it). I avoid
using netserver because of this and instead use netsend/netreceive to
a perl server that mediates. I never have the problem of hanging
ports with perl.
On 5-Jun-07, at 3:38 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Try this from the Terminal:
killall -KILL pd
in my experience this does not help with hung [netreceive] objects. even more, i sometimes do have no pd-process any more anyhow
(because it was quitted) and still the port is blocked and therefore not [netreceive] can be created.it would be interesting to know which process actually locks the port ("lsof -i" usually does not reveal anything in these cases). if nothing else helps, a reboot will do (rebooting might be faster
than waiting a couple of minutes)i don't know of any (pd-side) solution to this problem, that won't
make things worse. one (probably not so good) idea would be to actually create the object and try to get the port in a background process. however, this will make things very hard to debug.masd.r IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
-- Pall Thayer palli@pallit.lhi.is http://www.this.is/pallit
Pall Thayer wrote:
There's nothing you can do about a hung port short of rebooting the machine. This has always been a problem with the netserver and flashserver objects (maybe someone should look into it). I avoid using netserver because of this and instead use netsend/netreceive to a perl server that mediates. I never have the problem of hanging ports with perl.
How about having a few different ports and using another if one is not available? Since the TCP/IP stack is still working (it just thinks the port is still in use) there is nothing to stop you using another one.
Martin
Max Neupert wrote:
hi list,
i have the problem that after a crash or just a reopen of a patch
with the netserver object (i believe netreceive will have the same
issue) i need to wait a couple of seconds up to a minute until pd
allows me to open the same patch with a successful creation of the
netserver object, because the port seems to be already (still) in use.is there a way to force the port to reset or close? it's a little
annoying especially in live situations if everybody has to wait....m..
---8<--- The problem is related to the fact that "close()" does not ends the connection UNTIL the last of the file descriptors refering to the socket is closed. If other process has a copy of the file descriptor then it doesn't matter if you close your copy, the other copies MUST be closed in order for the socket to be really closed... ---8<--- http://developerweb.net/forum/archive/index.php/t-3480.html
Not sure what the solution is, though. It's certainly not a trivial problem to solve. If you can set up the clients to periodically ping the netserver and if there is no reply then disconnect, that might help.
hello max
i was told, that it is not related to pd itself, but to the kernel. when connections are not properly closed, then the kernel sets the specific port into kind of a 'wait for closing'-state. sometimes it takes up to 10 minutes, until the state changes to 'finished', but only then this specific port is freed again and you can create a [netserver] again. (this is a very clumsy explanation, someone with a deeper understanding of how the kernel handels tcp connections could explain that much more adequate). anyway, i think there is no workaround for this on the pd-side, it seems. i had the impression, that in case of a server-crash, it helps, when each connected client closes the connection (read: send a [disconnect(-message to [netclient]), although the connection seems already closed. netpd suffers from this problem as well.
roman
On Tue, 2007-06-05 at 02:50 +0200, Max Neupert wrote:
hi list,
i have the problem that after a crash or just a reopen of a patch
with the netserver object (i believe netreceive will have the same
issue) i need to wait a couple of seconds up to a minute until pd
allows me to open the same patch with a successful creation of the
netserver object, because the port seems to be already (still) in use.is there a way to force the port to reset or close? it's a little
annoying especially in live situations if everybody has to wait....m..
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
-
Claude Heiland-Allen -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Martin Peach -
Max Neupert -
Pall Thayer -
Roman Haefeli