* [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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).