9front - general discussion about 9front
 help / color / mirror / Atom feed
* [9front] rconnect via aan reliability patch
@ 2021-08-30 22:24 Xiao-Yong Jin
  2021-08-31  7:55 ` cinap_lenrek
  0 siblings, 1 reply; 6+ messages in thread
From: Xiao-Yong Jin @ 2021-08-30 22:24 UTC (permalink / raw)
  To: 9front

With long distance or slow network, the aanclient in rconnect
occasionally could fail to read the aan address sent by aanserver
with error:

	read: error reading <stdin>: i/o on hungup channel

This patch adds an additional synchronization by sending a message
from aanclient back to aanserver.

diff 61f37abf576a02c7f1e3561cfaba3c0457f55c9d uncommitted
--- a//rc/bin/rconnect
+++ b//rc/bin/rconnect
@@ -50,11 +50,12 @@
 	fn aanserver {
 		~ $#netdir 1 || netdir=/net/tcp/clone
 		netdir=`{basename -d $netdir} || exit
-		<>$netdir/clone {
-			netdir=$netdir/`{read} || exit
+		<>[4]$netdir/clone {
+			netdir=$netdir/`{read <[0=4]} || exit
 			>[3] $netdir/ctl {
 				echo -n 'announce *!0' >[1=3]
 				echo `{cat $netdir/local} || exit
+				~ `{read} OK || exit
 				bind '#|' /mnt/aan || exit
 				exec aan -m $aanto $netdir <>/mnt/aan/data1 >[1=0] >[2]/dev/null &
 			}
@@ -72,7 +73,7 @@
 	}
 	fn aanclient {
 		host=`{echo $host | sed 's/(.*)!([^!]+)$/\1/'}^!^`{read | sed 's/(.*)!([^!]+)$/\2/'} || exit
+		echo OK || exit
 		tlsclient -a -o <>{rfork s; aan -m $aanto -c $host >[1=0]} /bin/rc -c 'sendscript $*' $*
 	}
 	exec $argv0 -k $"keyspec $host <{builtin whatis aanserver; pvar aanto; echo aanserver} aanclient $*


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [9front] rconnect via aan reliability patch
  2021-08-30 22:24 [9front] rconnect via aan reliability patch Xiao-Yong Jin
@ 2021-08-31  7:55 ` cinap_lenrek
  2021-08-31 18:38   ` Xiao-Yong Jin
  0 siblings, 1 reply; 6+ messages in thread
From: cinap_lenrek @ 2021-08-31  7:55 UTC (permalink / raw)
  To: 9front

how does this work? how is adding another roundtrip fixing
a hung up tcp connection?

the patch is probably fine, but i do not understand what it
is fixing here...

--
cinap

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [9front] rconnect via aan reliability patch
  2021-08-31  7:55 ` cinap_lenrek
@ 2021-08-31 18:38   ` Xiao-Yong Jin
  2021-09-01  1:20     ` cinap_lenrek
  0 siblings, 1 reply; 6+ messages in thread
From: Xiao-Yong Jin @ 2021-08-31 18:38 UTC (permalink / raw)
  To: 9front

Write does not block.  Read does.  In the case with read errors,
the aanserver end did everything before aanclient starts to read
the address, and somehow the channel has hung up before the read.
The extra read in aanserver blocks the aanserver at that point and
wait for the OK signal from aanclient before continuing.

The thing I don't understand is that what actually makes the channel
hang up.  Do you have any suggestions as to how to debug this issue?

> On Aug 31, 2021, at 2:55 AM, cinap_lenrek@felloff.net wrote:
> 
> how does this work? how is adding another roundtrip fixing
> a hung up tcp connection?
> 
> the patch is probably fine, but i do not understand what it
> is fixing here...
> 
> --
> cinap


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [9front] rconnect via aan reliability patch
  2021-08-31 18:38   ` Xiao-Yong Jin
@ 2021-09-01  1:20     ` cinap_lenrek
  2021-09-06 14:58       ` mrowczok
  0 siblings, 1 reply; 6+ messages in thread
From: cinap_lenrek @ 2021-09-01  1:20 UTC (permalink / raw)
  To: 9front

> Write does not block.  Read does.

i know.

> In the case with read errors, the aanserver end did everything
> before aanclient starts to read the address, and somehow the channel
> has hung up before the read.

yeah, but we really need to figure out why. we might have a bug
in the tcp stack here, or you might just have some mtu issues
in your network.

i'm not going to blindly change protocols to tamper over mysterious
tcp connection problems.

> The extra read in aanserver blocks the aanserver at that point and
> wait for the OK signal from aanclient before continuing.

yes, i understand that.

> The thing I don't understand is that what actually makes the channel
> hang up.  Do you have any suggestions as to how to debug this issue?

i never had these issues. is it reproducable for you?

we can start by making packet captures with snoopy or wireshark.

if it is sporadic, we could also try to provoke it by doing the
exact opposite to your patch and delaying the client with a sleep
maybe? it could also be possible that it is closed my ourselfs
somehow by accident.

--
cinap

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [9front] rconnect via aan reliability patch
  2021-09-01  1:20     ` cinap_lenrek
@ 2021-09-06 14:58       ` mrowczok
  2021-09-06 16:23         ` cinap_lenrek
  0 siblings, 1 reply; 6+ messages in thread
From: mrowczok @ 2021-09-06 14:58 UTC (permalink / raw)
  To: 9front

hey,
some days ago i tested ftp server to see what speeds capable is 9front
virtual machine,
i'm using old installment - i wanted to test it on fresh system before
posting on net/irc but maybe it is related

somehow downloading file from ftp client on another pc manages to
broke all connectivity on guest system,
drawterm is unable to connect, 9p disk service is down.

strange thing is that displaying netstat output on guest/cpu lags on
certain moment.

testing was done with 650mb file and can be reproduced.

Stuff:
guest:
cwfs from 2016
kernel recompiled in august 2019.

host:
vmware workstation 15.5.5 build-16285975
Qualcomm/Atheros e2200 PCI-E Gigabit Ethernet Controller
(with jumbo frames 9KB MTU)



śr., 1 wrz 2021 o 11:24 <cinap_lenrek@felloff.net> napisał(a):
>
> > Write does not block.  Read does.
>
> i know.
>
> > In the case with read errors, the aanserver end did everything
> > before aanclient starts to read the address, and somehow the channel
> > has hung up before the read.
>
> yeah, but we really need to figure out why. we might have a bug
> in the tcp stack here, or you might just have some mtu issues
> in your network.
>
> i'm not going to blindly change protocols to tamper over mysterious
> tcp connection problems.
>
> > The extra read in aanserver blocks the aanserver at that point and
> > wait for the OK signal from aanclient before continuing.
>
> yes, i understand that.
>
> > The thing I don't understand is that what actually makes the channel
> > hang up.  Do you have any suggestions as to how to debug this issue?
>
> i never had these issues. is it reproducable for you?
>
> we can start by making packet captures with snoopy or wireshark.
>
> if it is sporadic, we could also try to provoke it by doing the
> exact opposite to your patch and delaying the client with a sleep
> maybe? it could also be possible that it is closed my ourselfs
> somehow by accident.
>
> --
> cinap

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [9front] rconnect via aan reliability patch
  2021-09-06 14:58       ` mrowczok
@ 2021-09-06 16:23         ` cinap_lenrek
  0 siblings, 0 replies; 6+ messages in thread
From: cinap_lenrek @ 2021-09-06 16:23 UTC (permalink / raw)
  To: 9front

oh yeah, that can definitely be related. why's the kernel 2 years
old tho? what ethernet device does the guest see? virtio?

--
cinap

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-09-06 16:30 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-30 22:24 [9front] rconnect via aan reliability patch Xiao-Yong Jin
2021-08-31  7:55 ` cinap_lenrek
2021-08-31 18:38   ` Xiao-Yong Jin
2021-09-01  1:20     ` cinap_lenrek
2021-09-06 14:58       ` mrowczok
2021-09-06 16:23         ` cinap_lenrek

9front - general discussion about 9front

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/9front

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 9front 9front/ https://inbox.vuxu.org/9front \
		9front@9front.org
	public-inbox-index 9front

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.9front


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git