hi, i recently stumbled upon some weird behaviour when i tried to connect 2 computers via netsend using the TCP protocol.
this is on Windows 7 / 64bit, PD 0.49.0:
so i hooked up 2 PCs with a network cable and fixed IP addresses. everything works fine. i can ping, i can send udp data to and from.
but now comes the weird situation:
when i try to connect with a TCP protocol to a valid IP address, but the port on the other machine is not yet opened (i.e. no [netreceive] has been created on the other computer), then my local PD freezes for about 20 (!) seconds before printing an error to the console.
if i try to connect to a "localhost" non-existing port, there's still a small PD freeze but only for about 1 second.
also irritating is the fact, that an invalid connection doesn't output a 0 on the left output, but instead does nothing. only the [disconnect( message outputs a 0.
i would expect a non existing connection (whether it's because of an invalid IP-address or a wrong port number) to just immediately output an error on the console AND output a 0 on the left output of [netsend], right ?
i am no expert in this field, so it might be that this behaviour is normal, though it doesn't seem right to me to stall a program for 20 seconds because of a worng network connection. i also experienced this behaviour with iemnet's [tcpsend] and [tcpclient].
i attached a patch with the described scenarios.
thanks for any help or wisdom !
best
oliver
hi, check this out: https://github.com/pure-data/pure-data/issues/378
TL;DR: [connect( tries to establish a connection until it times out. currently, the default timeout is system dependend, but it would be nice if we could also set it manually. and yes, the default timeout should be a bit shorter ;-). it's easy to implement, I wanted to make a PR but forgot...
Christof
Gesendet: Dienstag, 29. Januar 2019 um 01:24 Uhr Von: "oliver" oliver@klingt.org An: "pd-list@mail.iem.at" pd-list@mail.iem.at Betreff: [PD] TCP weirdness ? ...
hi, i recently stumbled upon some weird behaviour when i tried to connect 2 computers via netsend using the TCP protocol.
this is on Windows 7 / 64bit, PD 0.49.0:
so i hooked up 2 PCs with a network cable and fixed IP addresses. everything works fine. i can ping, i can send udp data to and from.
but now comes the weird situation:
when i try to connect with a TCP protocol to a valid IP address, but the port on the other machine is not yet opened (i.e. no [netreceive] has been created on the other computer), then my local PD freezes for about 20 (!) seconds before printing an error to the console.
if i try to connect to a "localhost" non-existing port, there's still a small PD freeze but only for about 1 second.
also irritating is the fact, that an invalid connection doesn't output a 0 on the left output, but instead does nothing. only the [disconnect( message outputs a 0.
i would expect a non existing connection (whether it's because of an invalid IP-address or a wrong port number) to just immediately output an error on the console AND output a 0 on the left output of [netsend], right ?
i am no expert in this field, so it might be that this behaviour is normal, though it doesn't seem right to me to stall a program for 20 seconds because of a worng network connection. i also experienced this behaviour with iemnet's [tcpsend] and [tcpclient].
i attached a patch with the described scenarios.
thanks for any help or wisdom !
best
oliver
-- \\\\\\\\\\\\\\\\\\\\\\\\\\\\ /////////////// http://pendler.klingt.org ////////////// \\\\\\\\ http://oliver.klingt.org \\\\\\\ //////////////////////////////////////////////////////// _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Christof Ressi wrote:
hi, check this out: https://github.com/pure-data/pure-data/issues/378
TL;DR: [connect( tries to establish a connection until it times out. currently, the default timeout is system dependend, but it would be nice if we could also set it manually. and yes, the default timeout should be a bit shorter ;-). it's easy to implement, I wanted to make a PR but forgot...
thanks for the insight !
yeah, i figured it was related to the OS.
anyway, up until a settable timeout is available, i can live with that situation and try to avoid to connect to ports, that aren't open ;-)
best
oliver
situation and try to avoid to connect to ports, that aren't open ;-)
or ping them first in the command line :-D
Gesendet: Dienstag, 29. Januar 2019 um 23:25 Uhr Von: "oliver" oliver@klingt.org An: "pd-list@mail.iem.at" pd-list@mail.iem.at Betreff: Re: [PD] TCP weirdness ? ...
Christof Ressi wrote:
hi, check this out: https://github.com/pure-data/pure-data/issues/378
TL;DR: [connect( tries to establish a connection until it times out. currently, the default timeout is system dependend, but it would be nice if we could also set it manually. and yes, the default timeout should be a bit shorter ;-). it's easy to implement, I wanted to make a PR but forgot...
thanks for the insight !
yeah, i figured it was related to the OS.
anyway, up until a settable timeout is available, i can live with that situation and try to avoid to connect to ports, that aren't open ;-)
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Wed, 2019-01-30 at 01:02 +0100, Christof Ressi wrote:
situation and try to avoid to connect to ports, that aren't open ;- )
or ping them first in the command line :-D
ping doesn't help much with testing for open ports. nc (netcat) can be used, but it behaves the same: If it receives no response, it waits for TIMEOUT seconds.
BTW: It depends on the other end's firewall whether a connection attempt fails immediately or only after a while. Firewalls can be configured to REJECT connections to closed ports, which means a notification (ICMP message, probably, I'm not sure) is sent to the initiating party, or the can be configured to DROP connections to closed ports -> no notification is sent. Without notification, the initiating party cannot know whether the receiving end is still processing the request or if it was silently dropped. That's why the default timeouts are so large.
Roman
-
Christof Ressi -
oliver -
Roman Haefeli