[ ホームページ ] [ 携帯用URL ]
将棋所のサポート掲示板
将棋所についての質問やバグ報告、USIエンジンの作成報告などに使用して下さい。

[ EZBBS.NET | 新規作成 | ランキング | オプション ]
ｉモード＆（絵文字）、au対応！ケータイからも返信できる無料掲示板！
名前
 E-mail 
題名
内容
   タグ有効 改行有効 等幅フォント
URL


1077．(untitled) 返信  引用 
名前：Mizar    日付：2020/9/23(水) 14:10
WiMAXルータでの無通信タイムアウトによってTCPソケットの経路上でサイレントで切断された症状のように思われます。

クライアント側・サーバ側・もしくはその両方にて、TCP KeepAliveを有効にし、適切な生存確認の間隔を設定する方法を検討しても良いかと思います。

shogi-server を Linux上で動作させていた場合の例ですが、

https://ja.osdn.net/projects/shogi-server/scm/git/shogi-server/blobs/master/shogi-server
shogi-server:492 に記述がありますが、tcp_keepalive_timeなどの設定値を変更することが考えられます。
```
client.setsockopt(Socket::SOL_SOCKET, Socket::SO_KEEPALIVE, true)
# Keepalive time can be set by /proc/sys/net/ipv4/tcp_keepalive_time
```

https://tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/

サーバ側の設定変更案)
tcp_keepalive_time を 7200 から 60 に変更
tcp_keepalive_intvl を 75 から 5 に変更
tcp_keepalive_probes は 9 のまま
（生存確認を60秒おきに行う、応答が無ければ5秒おきに再送、9連続で応答が無ければ接続を閉じる）

クライアント側(Windows)に関しては、レジストリキー HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Service\TCPIP\Parameters の KeepAliveTime のREG_DWORD値を短めに設定する、プログラム側でもTCPソケット接続作成時にKeepAliveを有効にする、等があるかもしれません。（詳細は未確認です）
https://docs.microsoft.com/ja-jp/windows/win32/winsock/so-keepalive


1079．Re: (untitled)
名前：Mizar    日付：2020/9/24(木) 1:11
https://docs.microsoft.com/ja-jp/windows/win32/api/winsock2/nf-winsock2-wsaioctl
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/dd877220(v=vs.85)

http://hei.techblog.jp/archives/2223221.html
https://n1dalap.hatenablog.com/entry/2014/08/04/232057

恐らく、レジストリを弄らなくてもSocketを生成してからconnect()するまでの間に、設定値を記したtcp_keepalive構造体を用意してからWSAIoctl()でKeepAliveの設定値を変更して有効化出来るという話かと思います。

1081．Re: (untitled)
名前：Mizar    日付：2020/9/24(木) 10:56
お互いに無通信状態になった場合の疎通を確認できるよう、クライアント側とサーバ側の双方でTCP Keep-Aliveを有効にして、適切な確認の間隔を設定すべきだと思います。

TCP Keep-Aliveが動作しているかどうかについては、将棋所のデバッグコンソールを確認するだけでは限界がありますので、WireSharkなどのネットワークアナライザを使って確認した方が良いです。

サーバ側のみでTCP Keep-Aliveを有効にした際の実験例:
https://twitter.com/mizarjp/status/1308943548041949184

WireSharkの導入と解析例:
https://beginners-network.com/wireshark.html
https://beginners-network.com/wireshark_analyze.html


Windowsクライアント側における実装想定例:
```
#include <Mstcpip.h> // struct tcp_keepalive のため

SOCKET mySock;
tcp_keepalive tcpKeepalive;
DWORD dReturn;

tcpKeepalive.onoff = 1; // 非ゼロならオン
tcpKeepalive.keepalivetime = 60000; // KeepAliveを実施する無通信時間
(ミリ秒）
tcpKeepalive.keepaliveinterval = 1000; // KeepAliveの応答が無い場合の再送間隔（ミリ秒）
WSAIoctl(*mySock, SIO_KEEPALIVE_VALS, &tcpKeepalive, sizeof(tcpKeepalive), NULL, 0, &dReturn, NULL, NULL);
```

1083．Re: (untitled)
名前：Mizar    日付：2020/9/25(金) 15:16
TCP KeepAliveでは含まれるデータサイズが0バイト長のストリーム送信に該当します（余計な改行文字やコマンド文字列を送っても良いか、といった議論を行う必要がありません）。TCP KeepAlive自体は必須の実装ではないため、動作しない環境が存在する可能性もありますが、一般的なWindowsやLinux環境では動作するものですし、floodgateモードに限らずCSAモードでの接続などでも対応できそうなものですので、実装を検討してみてはいかがでしょうか。

参考) RFC1122 TRANSPORT LAYER -- TCP (October 1989) 日本語訳
https://jprs.jp/tech/material/rfc/RFC1122-ja.txt
```
4.2.3.6 TCP接続のキープアライブ

"キープアライブ"は広く受け入れられているものではないが、
実装者は、TCP実装にこの機能を組み込んでもよい(MAY)。
キープアライブが組み込まれている場合、アプリケーションは、
TCP接続ごとに機能を有効または無効にできなければならず(MUST)、
またデフォルトは無効でなければならない(MUST)。

キープアライブパケットは、一定期間内に接続に関するデータ
パケットも確認応答パケットも受信されなかった場合にのみ送信
されなければならない(MUST)。この期間は設定可能でなければ
ならず(MUST)、またデフォルトは2時間以上でなければならない
(MUST)。

データを含まないACKセグメントは、TCPによる確実な転送が
なされないことを思い出すことは極めて重要である。この理由に
より、キープアライブの仕組みが実装されている場合、いかなる
死活確認(probe)の失敗であっても、それを接続障害と解釈しては
ならない(MUST NOT)。

実装は、データを持たないキープアライブセグメントを送信すべき
である(SHOULD)。しかし、誤ったTCP実装との互換性のために、
1オクテットの不要データ(one garbage octet)を含めてキープ
アライブセグメントを送信するように設定可能であってもよい(MAY)。

【 議論 】
"キープアライブ"の仕組みは、それを行わないと接続が
アイドル状態になってしまう場合に、たとえ送信されるデータ
が無くても接続の対向側に対して死活確認を行うものである。
TCP仕様はキープアライブの仕組みを含まない。その理由は
以下の通りである。(1)一時的なインターネット障害の間に、
完璧に良好だった接続を壊してしまう可能性がある。(2)不要
な帯域を消費する可能性がある("誰も接続を使用していない
のなら、その接続がまだ良好かはどうでもよいのでは？")。
(3)パケット従量課金するインターネットパスではコストが
かさむかもしれない。

しかし、一部のTCP実装はキープアライブの仕組みを組み
込んできた。アイドル状態の接続がまだ有効であることを
確認するため、これらの実装は、対向側TCPから応答を引き出す
ように設計された死活確認セグメントを送信する。そのような
セグメントは、一般にSEG.SEQ=SND.NXT-1を含み、1オクテット
の不要データを含む場合もあれば含まない場合もある。
平穏な接続ではSND.NXT=RCV.NXTになるので、このSEG.SEQ
はウインドウの範囲外であることに注意せよ。従って、
死活確認は受信者に確認応答セグメントを返させ、それにより
接続がまだ生きていることを確認する。対向側がネットワーク
からの隔絶またはクラッシュにより接続を打ち切っていた場合、
確認応答の代わりにRSTを応答するだろう。

残念なことに、一部の作法を守らないTCP実装は、セグメントが
データを含まない限りSEG.SEQ=SND.NXT-1のセグメントの応答に
失敗する。代替手段として、実装は、対向側が不要データ
オクテットを含まないキープアライブパケットに正しく応答して
きたかを判定して対処することもできるかもしれない。

TCPキープアライブの仕組みは、ネットワーク障害中に
クライアントがクラッシュまたはアボートした場合、キープ
アライブを行わないと無期限にハングアップし、リソースを
不必要に消費してしまうようなサーバーアプリケーションに
おいてのみ起動されるべきである。
```

1084．Re: (untitled)
名前：Mizar    日付：2020/9/25(金) 15:57
TCP KeepAliveで問題になる可能性としては、今の所以下のような点が考えられます。

どの程度の無通信時間(tcp_keepalive_time)でKeepAliveを送信するべきか（TCP KeepAliveはデフォルトでは2時間以上）、またKeepAliveの応答が無かった場合の再送間隔(tcp_keepalive_intvl)と最大再送回数(tcp_keepalive_probes)はどの程度とするか。（頻度が過少であれば障害を検出しにくく、頻度が過大であればネットワークのコストがかさむ、最大最小回数が過少であれば正常な通信対戦が続行できる程度の軽度の障害で切断してしまう恐れがある）

TCP KeepAliveの有効化で問題が起きる（対応していない、バグを抱えている）ネットワーク機器（宅内・ネットワーク接続提供者・サーバ側等の、ルータ、モデム、ファイアウォールなど）が経路上に存在しないかどうか。通信元・通信先の環境は共に対応しているかどうか。

1085．Re: (untitled)
名前：Mizar    日付：2020/9/25(金) 16:53
Winsock2にてソケットごとにキープアライブの間隔を設定するコード例:
http://read.pudn.com/downloads79/ebook/301417/Chapter09/SIO_KEEPALIVE_VALS/alive.c__.htm

1087．Re: (untitled)
名前：将棋所の作者    日付：2020/9/26(土) 15:2
TCP KeepAliveを設定すると、接続が切れたときに受信スレッドで例外が発生するようなのですが、受信スレッドでの例外というのは他の原因で発生することもあり、再ログインのイベントとしては使うには扱いにくいところがあります。TCP KeepAliveにより切断自体を防げる可能性もありますが、それを確かめるには長時間のテストが必要です。
現在検討している、対局中にKeepAliveを送る方法であれば、例外が発生した時の再ログインも簡単なので、とりあえずそれでテストしようと思っています。他の方法でうまくいかなければTCP KeepAliveも検討したいと思います。
1060．「転送接続にデータを書き込めません」時に自動的に再接続するオプション 返信  引用 
名前：nodchip@tanukk-    日付：2020/9/6(日) 9:1
コンピュータ将棋ソフト『tanuki-』シリーズ開発者代表、nodchipと申します。日頃よりコンピュータ将棋エンジンの開発に将棋所をを使用させていただいております。貴重なコンピュータ将棋GUIを公開してくださり、誠にありがとうございます。

先日、世界コンピュータ将棋オンライン電竜戦第3回予行演習に参加した際、以下のエラーメッセージが表示され、以降不戦敗となってしまいました。
https://drive.google.com/file/d/1Mi_uI5Ym1A9qiCQyLYDuMEm0I1qZymqo/view?usp=sharing

「転送接続にデータを書き込めません: 確立された接続がホスト コンピューターのソフトウェアによって中止されました。。」というメッセージが表示される場合に、サーバーに自動的に再接続するオプションを実装いただくことは可能でしょうか？

よろしくお願いいたします。


1061．Re: 「転送接続にデータを書き込めません」時に自動的に再接続するオプション
名前：Mizar    日付：2020/9/6(日) 9:34
```
>T:LOGIN sylwi (パスワード) x1
<T:LOGIN:sylwi OK
<T:##[LOGIN] +OK x1
>T:%%GAME floodgate-300-5F *
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
<T:BEGIN Game_Summary
<T:Protocol_Version:1.2
<T:Protocol_Mode:Server
<T:Format:Shogi 1.0
<T:Declaration:Jishogi 1.1
<T:Game_ID:dr1t3t1+sg-1_sylwi_daigo8-300-2F+sylwi+daigo8+20200905200138
<T:Name+:sylwi
<T:Name-:daigo8
<T:Your_Turn:+
<T:Rematch_On_Draw:NO
<T:To_Move:+
<T:Max_Moves:512
<T:BEGIN Time
<T:Time_Unit:1sec
<T:Total_Time:300
<T:Byoyomi:0
<T:Increment:2
<T:Least_Time_Per_Move:0
<T:END Time
<T:BEGIN Position
<T:P1-KY-KE-GI-KI-OU-KI-GI-KE-KY
<T:P2 * -HI * * * * * -KA *
<T:P3-FU-FU-FU-FU-FU-FU-FU-FU-FU
<T:P4 * * * * * * * * *
<T:P5 * * * * * * * * *
<T:P6 * * * * * * * * *
<T:P7+FU+FU+FU+FU+FU+FU+FU+FU+FU
<T:P8 * +KA * * * * * +HI *
<T:P9+KY+KE+GI+KI+OU+KI+GI+KE+KY
<T:+
<T:END Position
<T:END Game_Summary
>T:AGREE
>T:
>T:
<T:REJECT:dr1t3t1+sg-1_sylwi_daigo8-300-2F+sylwi+daigo8+20200905200138 by sylwi
>T:%%GAME floodgate-300-5F *
<T:転送接続からデータを読み取れません: 確立された接続がホスト コンピューターのソウトウェアによって中止されました。。
>T:
```

何らかの不具合により、対局サーバ側から対局不成立の原因が自分のせいにされる（REJECT: 〜 by sylwi）場合があるようで、不成立の原因とされた側の接続が対局サーバ側から切断されるようになっているようです。この場合はREJECTメッセージが送られて来た時点でサーバ側から接続が閉じられているので、次のゲームに再度参加しようとしても（%%GAME floodgate-300-5F *）、閉じられたソケットにデータを書き込むことが出来ず、例外が発生するという事のようです。

1062．Re: 「転送接続にデータを書き込めません」時に自動的に再接続するオプション
名前：Mizar    日付：2020/9/6(日) 9:45
```
>T:%%GAME floodgate-300-5F *
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
<T:BEGIN Game_Summary
<T:Protocol_Version:1.2
<T:Protocol_Mode:Server
<T:Format:Shogi 1.0
<T:Declaration:Jishogi 1.1
<T:Game_ID:dr1t3t1+sg-17_nanashogi_sylwi-300-2F+nanashogi+sylwi+20200906025222
<T:Name+:nanashogi
<T:Name-:sylwi
<T:Your_Turn:-
<T:Rematch_On_Draw:NO
<T:To_Move:+
<T:Max_Moves:512
<T:BEGIN Time
<T:Time_Unit:1sec
<T:Total_Time:300
<T:Byoyomi:0
<T:Increment:2
<T:Least_Time_Per_Move:0
<T:END Time
<T:BEGIN Position
<T:P1-KY-KE-GI-KI-OU-KI-GI-KE-KY
<T:P2 * -HI * * * * * -KA *
<T:P3-FU-FU-FU-FU-FU-FU-FU-FU-FU
<T:P4 * * * * * * * * *
<T:P5 * * * * * * * * *
<T:P6 * * * * * * * * *
<T:P7+FU+FU+FU+FU+FU+FU+FU+FU+FU
<T:P8 * +KA * * * * * +HI *
<T:P9+KY+KE+GI+KI+OU+KI+GI+KE+KY
<T:+
<T:END Position
<T:END Game_Summary
>T:AGREE
>T:
>T:
>T:
<T:REJECT:dr1t3t1+sg-17_nanashogi_sylwi-300-2F+nanashogi+sylwi+20200906025222 by nanashogi
>T:%%GAME floodgate-300-5F *
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
>T:
<T:BEGIN Game_Summary
<T:Protocol_Version:1.2
<T:Protocol_Mode:Server
<T:Format:Shogi 1.0
<T:Declaration:Jishogi 1.1
<T:Game_ID:dr1t3t1+sg-18_sylwi_hosshii-300-2F+sylwi+hosshii+20200906030923
<T:Name+:sylwi
<T:Name-:hosshii
<T:Your_Turn:+
<T:Rematch_On_Draw:NO
<T:To_Move:+
<T:Max_Moves:512
<T:BEGIN Time
<T:Time_Unit:1sec
<T:Total_Time:300
<T:Byoyomi:0
<T:Increment:2
<T:Least_Time_Per_Move:0
<T:END Time
<T:BEGIN Position
<T:P1-KY-KE-GI-KI-OU-KI-GI-KE-KY
<T:P2 * -HI * * * * * -KA *
<T:P3-FU-FU-FU-FU-FU-FU-FU-FU-FU
<T:P4 * * * * * * * * *
<T:P5 * * * * * * * * *
<T:P6 * * * * * * * * *
<T:P7+FU+FU+FU+FU+FU+FU+FU+FU+FU
<T:P8 * +KA * * * * * +HI *
<T:P9+KY+KE+GI+KI+OU+KI+GI+KE+KY
<T:+
<T:END Position
<T:END Game_Summary
>T:AGREE
<T:START:dr1t3t1+sg-18_sylwi_hosshii-300-2F+sylwi+hosshii+20200906030923
>T:+2726FU,'* 46 -4132KI +2625FU -8384FU
<T:+2726FU,T0
```

のように、対局不成立の原因が相手であるように示された場合(REJECT:dr1t3t1+sg-17_nanashogi_sylwi-300-2F+nanashogi+sylwi+20200906025222 by nanashogi)は対局サーバ側から切断されることがなく、そのまま次のゲームに参加出来ていました。

1063．Re: 「転送接続にデータを書き込めません」時に自動的に再接続するオプション
名前：将棋所の作者    日付：2020/9/6(日) 15:8
報告ありがとうございます。調べてみるのでしばらくお待ちください。

1064．Re: 「転送接続にデータを書き込めません」時に自動的に再接続するオプション
名前：Mizar    日付：2020/9/7(月) 21:44
https://ja.osdn.net/projects/shogi-server/scm/git/shogi-server/blobs/master/shogi_server/player.rb

何らかの要因（多重ログイン？）で、shogi-server の class Player の kill が呼び出されたと疑っていますが、コンソールに出力されたログは保存していなかったとの事で、今の所は対局サーバ側の詳しい原因は特定出来ていません。

1065．Re: 「転送接続にデータを書き込めません」時に自動的に再接続するオプション
名前：将棋所の作者    日付：2020/9/9(水) 19:56
Mizarさんの情報によると、REJECTが返ってきた場合、その原因が自分側か相手側によって状況が異なるので、それによって解決法も異なり、

・自分側が原因であれば既に接続が閉じられているので、コマンドを送ることができない。そのため、新規にログインして、次の対局が始まるのを待つ。
・相手側が原因であれば、%%GAMEでgamenameを送れば対局待ちになり、次の対局に参加できる（現状、REJECTの原因がどちら側かに関係なくgamenameを送っているので、相手側が原因なら現状の実装と同じ）

ということになるでしょうか。そのように修正することはできるかもしれませんが、それで問題解決になっているのかよくわからないところがあります。
まず、そのように修正したとして、自分側が原因の場合、再ログインが正常にできるかどうか、テストが面倒です。floodgateでテストするにしても、REJECTが返ってくることは滅多にないので、動作検証が簡単ではありません。
また、それで次の対局に進めるとしても、そのラウンドに関しては対局できないことに違いはないので、floodgateならともかく、大会の場合にはやはり問題になります。

そもそもの問題として、対局開始前にREJECTが返ってくるのはなぜか、というのがあります。大会に使うサーバの場合、あらかじめ登録した人だけがログインできて、その全員がサーバのマッチメイクに従って対局開始を待っているはずですから、サーバがREJECTを返す理由がわからないし、それがなければこの問題は起きないはずです。
CSAプロトコルでは、REJECTというのはクライアント側がそれを送って対局を拒否した場合だけサーバから送られてくるはずで、クライアントがREJECTを送るはずがない今回のような大会でサーバがREJECTを送るというのは、やはりサーバ側の実装に問題があると思います。
最初に書いた修正方法にしても、現状のサーバがそうなっているからそれに合わせるという話で、それならサーバを修正する方が筋だろうし、将棋所の側がサーバのおかしな実装に合わせるのは、どうにも気が進まないところがあります。

あと、今回の大会は将棋所のテスト版１が使用されたようですが（Keep Aliveの間隔を短くするだけではあまり効果なかったようですが）、テスト版２の方はどれくらい効果あるのか、それを知りたいところです。

1066．Re: 「転送接続にデータを書き込めません」時に自動的に再接続するオプション
名前：カツ丼将棋    日付：2020/9/10(木) 20:39
将棋所の作者様

お世話になっております。いろいろご対応いただいていつもありがとうございます。
私がこれまで幾多の実験をした目線で状況をご説明していただきます。

＞そもそもの問題として、対局開始前にREJECTが返ってくるのはなぜか、というのがあります。

通常であればAgree待ちの状態で1分経過すると(設定可)、自動でREJECTを送るようになっています。将棋所の設定でREJECTされてもログアウトしないの設定にしていればログインが継続できて大会が継続できます。
将棋所は自動でAGREEを返すので普通はそうなることはありません。

一方で、クライアント側の通信環境が不調であると、サーバーが対局条件を送って%%WHOのステータスがAgree待ちになっているにもかかわらず、実際にはクライアント側には届いていないかのようになって、クライアント側はずっと待ちの状態で、タイムアウトでサーバーがREJECTをします。

で、今回何が問題かというと、そういう状態になってREJECTされたとしても将棋所の設定でログイン状態かと思っていたら、nodchipさんにあるようなエラーを吐いてログアウト状態になったことです。
自分の通信環境が低スペックのため自分だけ落ちるのはお前が悪い、で片付けることもできるのですが、対戦相手がログアウトになって以降不戦敗となるのはどうしても許容できません。

＞また、それで次の対局に進めるとしても、そのラウンドに関しては対局できないことに違いはないので、floodgateならともかく、大会の場合にはやはり問題になります。

ログインさえしといてもらえれば、私の電竜戦管理ツールが検知してそのラウンドの対局のマッチメイクをかけるようになっております。
なので、私の要望としては、どういう理由でログアウトされようと、ログアウトされたらもう一度ログインする、実はそれだけが要望です。

＞テストが面倒です。
おっしゃる通り、再現させるのが面倒です。。。ただこれまでの経験則から、Agree処理でトラブるのはいつも同じ人です。即ち回線がプアだとこの問題を起こしやすいです。自分でももう少し再現させて状況を見てみます。

＞あと、今回の大会は将棋所のテスト版１が使用されたようですが
私の手元の実験で、テスト版1で満足な結果が得られたのでテスト版1を採用しました。ただ今回Agree処理のトラブルが起こった状態で、もう一度ログアウト・ログインすると回復を致しましたので、テスト版２の方がよいという気がしています。
次回のテストは10月24日を予定しておりまして、テスト版2を使用するつもりでいます。

長くなりましたのでまとめますと
　・現状のサーバがどうであれ、ログアウトしてたらログインしてもらるだけでよい
　・もう少しテストして挙動をみてみます。
　・次回の10月24日の予行演習はテスト2を使います。

以上よろしくお願いします。

1067．Re: 「転送接続にデータを書き込めません」時に自動的に再接続するオプション
名前：カツ丼将棋    日付：2020/9/11(金) 22:49
テスト版2ですいしょう70体でシミュレーションをしてみました。

https://golan.sakura.ne.jp/denryusen/dr1_test4a/dr1_live.php
(近日消しますが)

2回実験をしまして、
●1回目：再ログインを1分・・・・マッチメイクを何度もリトライすることとなり運営に支障がありました、、、

●2回目：再ログインを20分・・・トラブルは一つもありませんでした。
　快適だと思いました。ただ私の家の回線は割とよい方なのでこれをもってテスト版2が有意であると必ずしもいえるわけではありませんが、、、

いずれにせよ10月24日の予行演習4はテスト版2を参加者にお願いしてみようと考えております。

1068．Re: 「転送接続にデータを書き込めません」時に自動的に再接続するオプション
名前：将棋所の作者    日付：2020/9/12(土) 12:48
サーバの動作について確認したいことがあります。

>一方で、クライアント側の通信環境が不調であると、サーバーが対局条件を送って%%WHOのステータスがAgree待ちになっているにもかかわらず、実際にはクライアント側には届いていないかのようになって、クライアント側はずっと待ちの状態で、タイムアウトでサーバーがREJECTをします。

この、サーバがREJECTを送った直後の動作ですが、Mizarさんによると、REJECTの原因となった側の接続はサーバ側が切断してしまい、その対戦相手の方はそのまま接続が続くということですが、それで正しいでしょうか。
nodchipさんはYoutubeで実況していたはずで、回線には問題なかったと思いますので、nodchipさんにREJECTが送られてきたのであれば相手側が原因だと思いますが、それであればnodchipさんの接続が切断されることはなく、gamenameを送ることで次の対局に進めると思います。
実際のところ、nodchipさんのところではアラートが出て対局がストップしたわけで、gamenameを送る時点で既に切断されていたと思いますが、相手側に原因があったとしても、その対戦相手の接続が切断されることもあるのでしょうか。
あるいは、自分側の接続に問題がなくても、なぜか自分側に問題があるとサーバが判断してしまい、それでREJECTが送られた直後に切断される、ということがあるのでしょうか。
そのあたり詳しいことを知りたいです。

1069．Re: 「転送接続にデータを書き込めません」時に自動的に再接続するオプション
名前：カツ丼将棋    日付：2020/9/13(日) 22:4
>そのあたり詳しいことを知りたいです。

再現が難しいところですが、頑張って再現してみます。

一方で、私としては挙動がどうであれ例外(転送接続にデータを書き込めません・・・)をキャッチしたらもう一度再接続すればそれでいいです。そこで下記リンクにあります通り、外部ツールを用いまして私の方で例外をキャッチしたら再接続する外部プログラムを作りました。
https://twitter.com/katsudonshogi/status/1304735715939368960

ひとまずはこれで未接続で不戦敗が続くことはないと思っていますが、キーボードの操作を使ったものなのでベストな方法だとは思ってないです。エラーポップアップが表示されたら30秒程度表示して、自動で閉じてもう一度再接続、といったのを実装していただけると私としてはありがたいです。

1070．Re: 「転送接続にデータを書き込めません」時に自動的に再接続するオプション
名前：将棋所の作者    日付：2020/9/14(月) 19:20
>一方で、私としては挙動がどうであれ例外(転送接続にデータを書き込めません・・・)をキャッチしたらもう一度再接続すればそれでいいです。

了解しました。当初は、サーバからREJECTが送られてきた直後に限り、コマンド送信に失敗したら再ログインするよう変更しようかと思っていました。しかし、サーバの挙動がはっきりわからないので、タイミングに関係なく、floodgate接続中にコマンド送信に失敗したら再ログイン、というようにしたいと思います。

>エラーポップアップが表示されたら30秒程度表示して、自動で閉じてもう一度再接続、といったのを実装していただけると私としてはありがたいです。

アラートを表示した場合、それを自動で閉じるのが難しいので、何もアラートを表示せずに自動で再ログイン、ただし再ログインにも失敗したらアラートを表示、というようにしようかと思います。
テスト版を公開するまでしばらくお待ちください。

1071．Re: 「転送接続にデータを書き込めません」時に自動的に再接続するオプション
名前：カツ丼将棋    日付：2020/9/14(月) 21:30
将棋所の作者様

私どもの要望を聞いていただけましてありがとうございます！

そのテスト版についてですが、テスト版2にある一定時間がくると再ログインする機能もあると大変助かります！

＞アラートを表示した場合、それを自動で閉じるのが難しいので、何もアラートを表示せずに自動で再ログイン、ただし再ログインにも失敗したらアラートを表示、というようにしようかと思います。

はい、それがベストです！。

1072．Re: 「転送接続にデータを書き込めません」時に自動的に再接続するオプション
名前：将棋所の作者    日付：2020/9/14(月) 22:31
>そのテスト版についてですが、テスト版2にある一定時間がくると再ログインする機能もあると大変助かります！

その機能も入れてテスト版３を作ろうと思うのでしばらくお待ちください。

1073．Re: 「転送接続にデータを書き込めません」時に自動的に再接続するオプション
名前：将棋所の作者    日付：2020/9/21(月) 23:54
先ほど、テスト版３を公開したので使ってみて下さい。

1074．Re: 「転送接続にデータを書き込めません」時に自動的に再接続するオプション
名前：カツ丼将棋    日付：2020/9/22(火) 21:47
将棋所の作者様

お忙しいところテスト版３を作成してくださり誠にありがとうございます！！
早速各種テストを実施します。
使ってみた感想等は逐次ご報告させていただきます！
1056．エンジン設定に空白を含む絶対パスを指定する方法 返信  引用 
名前：hakusa    日付：2020/8/16(日) 22:20
自前でエンジン設定のオプションを増やすことが可能だと思うのですが、そこで「空白を含む絶対パス」を登録しようとすると、空白部分から先がなくなってしまいます。

具体的には、以下のような挙動になります。

1.自前エンジン内でデフォルトの絶対パス(を含めたファイル名)を設定しています。

o["KShogi_exe"] << Option("C:\\Program Files \(x86\)\\Kakinoki\\KShogi9\\KShogi9.exe");

2.将棋所にエンジン登録したあと、対局→エンジン管理→エンジン設定を開くと、ちゃんと以下のように絶対パスを読み込みます。
<1:option name KShogi_exe type string default C:\Program Files (x86)\Kakinoki\KShogi9\KShogi9.exe

3.上記の設定画面を閉じ、すぐもう一度開くと、空白以降が消えてしまいます。
その状態で設定画面を閉じると、以下のようにセットされてしまいます。
>1:setoption name KShogi_exe value C:\Program

なお、エンジン内のデフォルト設定を以下のようにしても同じでした。
o["KShogi_exe"] << Option("\"C:\\Program Files \(x86\)\\Kakinoki\\KShogi9\\KShogi9.exe\"");

設定画面を開けるたんびにちゃんと設定し直せばいいんでしょうが、それしか方法はないものなんでしょうか。というかそもそもUSIの規則上空白を含む文字列をオプションとして登録することはできないんでしょうか。
なにかよい設定方法等があれば教えてください。よろしくお願いいたします。


1057．Re: エンジン設定に空白を含む絶対パスを指定する方法
名前：将棋所の作者    日付：2020/8/18(火) 20:33
報告ありがとうございます。半角スペースが含まれる場合のことは考慮していませんでした。
USIの規則では、optionnameにスペースを入れるのは禁止ですが、stringで指定する文字列にスペースが入っているのは特に問題ないような気がします。それで何か不具合が起きないかもうちょっと調べてみますが、それで問題ないのであれば修正しようと思うのでしばらくお待ちください。

1058．Re: エンジン設定に空白を含む絶対パスを指定する方法
名前：hakusa    日付：2020/8/19(水) 21:45
ありがとうございます。
よろしくお願いします。

1059．Re: エンジン設定に空白を含む絶対パスを指定する方法
名前：hakusa    日付：2020/9/4(金) 23:32
確認しました。ちゃんと出てます。
ありがとうございます。
ページ： 1 2 3 4 5 6 7 8 9 10 >> >| 

無料アクセス解析

アクセス解析の決定版！無料レンタルで最大100ページ解析！

   投稿KEY
   パスワード
EZBBS.NET produced by InsideWeb