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

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


1075．テスト版３での不具合例 返信  引用 
名前：48    日付：2020/9/23(水) 10:46
常日頃お世話になっております。
また，テスト版３の作成ありがとうございます。
さっそくWiMAXルータにWiFi接続という二段に危ない回線でテストしてみました。
USIエンジン起動ミスなどでは次戦が戦えていますが，下記ログでYss1000kはAGREE後初手を指さずに時間切れしたようです。
こちらは初手を5分ほど待っている間に回線切れをしたようでTIMEOUTを知らずにずっと相手の指し手を待っている状態でした。
長考時に切れるケースも他にありますので明らかに切れ負けの場合も再接続という対応できませんでしょうか。

http://wdoor.c.u-tokyo.ac.jp/shogi/view/show-player.cgi?event=LATEST&filter=floodgate&show_self_play=1&user=test3_test


1078．Re: テスト版３での不具合例
名前：将棋所の作者    日付：2020/9/23(水) 23:45
確認ですが、切れ負けの場合というのは、サーバから#TIME_UPが送られてきて対局終了した、ということでしょうか（その場合、対局結果一覧を開くと、その対局のコメント欄には「時間切れ」と書いてあると思います）
あるいは、対局開始後、サーバから何も送られて来ない状態が続いて接続が切れてしまい、対局中のように見える状態が何時間もずっと続いたまま、ということでしょうか。
前者であれば、#TIME_UPが送られてきて対局終了した場合は再ログイン、というようにすれば対応できると思います。後者の場合、再ログインするきっかけになるイベントが何もないので、どのように再ログインするか、対策を考える必要があります。

1080．Re: テスト版３での不具合例
名前：48    日付：2020/9/24(木) 7:28
説明不足ですみません。
後者です。TIMEOUTを認識していません。
夜中に対戦させた場合朝に数万秒の超過になっていることが多々あります。
相手の持ち時間から計算して明らかに時間切れの場合は再接続できませんでしょうか？
つまり駆動イベントはタイマーです。

電竜戦運営で確認してみたところ相手が長考に入った状態で回線が切れているケースが多いようです。
AGREE後初手待ちもその類です。
floodgateでは相手番でもkeepaliveを受け付けるらしいのでそういう対応でも回避できるかもしれません。
手番側が長考で切れるケースは少ないようです。

1082．Re: テスト版３での不具合例
名前：将棋所の作者    日付：2020/9/25(金) 0:1
>floodgateでは相手番でもkeepaliveを受け付けるらしいのでそういう対応でも回避できるかもしれません。

それであれば、対局開始後であっても、指し手の送受信がない状態が続いたら１分ごとにKeepAliveを送る、ということにしようかと思います。そうすれば、対局が止まって接続が切れても、KeepAliveの送信に失敗したときに再ログインできます。その機能を入れたテスト版４を作ろうと思うのでしばらくお待ちください。
それでも駄目なら、明らかな時間切れの場合に再ログイン、というのを作ろうかと思います。

1086．Re: テスト版３での不具合例
名前：カツ丼将棋    日付：2020/9/26(土) 13:45
将棋所の作者様

テスト版３を使って各種テストを致しましたので簡単に共有致します。
https://golan.sakura.ne.jp/denryusen/dr1_test4a/dr1_live.php
(すぐ消しますが、、、)

●まずこれまで問題になっていた、Agree処理で不安定になって相手の回線が切られる件、これについては私の拙作プログラムに間違いがあって、本来コールされることのない緊急用の不安定な人を乗っ取ってBANさせるコードが常に呼ばれるようになっていました、、、つまるところ私のヘマでして今後は同様のことはほとんど起こらないです。お騒がせしました。。ただそのテストの過程で接続復帰がちゃんとワークしていることを確認しました。これは大変有用な機能です。

●対局中に、デザリングでつないでいたものを途中wifiにつなぎ返したソフトがあったのですが、そうすると両者の回線が切れてしまってたようで、サーバーはそれに気づかず接続状態と勘違いし、またクライアント側もずっと対戦が続いているものと勘違いしているような挙動があり、次のラウンドの対戦を始める過程でサーバーが気付いてサーバーも接続切れと判断。クライアント側はずっと対戦が続いている、、、というのがありました。これはテスト版４で解決すると思っておりますのでお待ちしております。

●不安定な回線でAgree待ちをしていると、サーバー側が対局条件を送ったつもりでもクライアント側に届いておらず、サーバー側はタイムアウトでREJECTするのですが、両者の思い違いのない作りにしないと思っておりますが、なかなか再現できないケースなのでもっといろいろ再現させてまた共有致します。

1088．Re: テスト版３での不具合例
名前：将棋所の作者    日付：2020/9/27(日) 23:54
先ほど、テスト版４を公開したので使ってみて下さい。

1089．Re: テスト版３での不具合例
名前：カツ丼将棋    日付：2020/9/29(火) 0:5
将棋所の作者様

テスト版４を公開していただきありがとうございました。
早速テストさせていただきました。

ケース１）持ち時間２時間にして、数手指して放置
　⇒時間が切れてもサーバが反応しませんでした。再ログインしようにも将棋所からは接続が切れませんでしたので、×ボタンで強制終了させました。この際、待たされた方から先に落としました。片方だけ落としても、%%WHOするともう片方の方がゲーム状態で(これはおかしい状態)、それも×ボタンで落としてしまうとやっとサーバーが反応して、手番で時間を切らした方が負けるという、正しい勝敗が返ってきました。
これだと２時間長考したまま時間切れすると、サーバーがいつまでも対局状態となり、スイス式の大会の場合、次のラウンドに進めず大会運営が破綻します(真夜中の完全フルオートモードの場合)。


ケース２)持ち時間１時間にして、時間切れぎりぎりで手を指してみる
　⇒正しく対局ができました。対局中のkeepaliveが効果を出していると思われます。

ケース３)サーバー側にtcp keepaliveを設定し、ケース１と同じく２時間放置
　⇒ケース１と同じ症状。ここでは×で落とさずに手を指してみると、タイムアップが返ってきました。サーバのtcp keepaliveは効果が薄いように見えました。


以上のことから、ローカルタイムから計測して明らかに時間が切れている場合は再ログインする機能をするテスト版５をお願いできませんでしょうか？それで困っている問題はほぼ解決すると思っています。

　なお、対処しなければならない事象の優先度というのは、
不具合のため大会の進行が止まるケース >>> 不具合を起こした人のために対戦相手が以降不戦敗となるケース >>>>> 自分の不具合のため自分が以降不戦敗となるケース
と、考えております。

1090．Re: テスト版３での不具合例
名前：Mizar    日付：2020/9/29(火) 13:27
> ケース１）持ち時間２時間にして、数手指して放置

持ち時間1時間で3局ほど追試してみましたが、shogi-serverが指し手放置の時間切れを起こした対局について、#TIME_UPを返すタイミングが割と不定になっているため、多少の持ち時間超過では#TIME_UPを返してくれないように見える、という現象のように見受けられました。（それぞれ、持ち時間を約5分、約14分、約8分経過した時点でshogi-serverが#TIME_UPを返して対局打ち切り）

指し手放置の対局について切れ負けの通知#TIME_UPが遅れる件に関して、改修が必要なのはshogi-serverの側であるように見受けられます。

1092．Re: テスト版３での不具合例
名前：将棋所の作者    日付：2020/9/30(水) 23:19
> ケース１）持ち時間２時間にして、数手指して放置
　⇒時間が切れてもサーバが反応しませんでした。

> ケース３)サーバー側にtcp keepaliveを設定し、ケース１と同じく２時間放置
　⇒ケース１と同じ症状。ここでは×で落とさずに手を指してみると、タイムアップが返ってきました。

時間が切れた場合、すぐにサーバは適切なコマンドを送って対局を終了させる必要があります。それを送らないのであればサーバ側の問題になります。
サーバ通信対局において時間管理というのは全てサーバ側が行うので、クライアント側が時間切れかどうか判断することはありません。

1094．Re: テスト版３での不具合例
名前：Mizar    日付：2020/10/1(木) 11:48
テスト版4でshogi-serverでの対局中、着手放置で時間切れになった場合になかなかサーバ側が時間切れを検知できなかった件のついてですが、

https://osdn.net/projects/shogi-server/scm/git/shogi-server/blobs/master/shogi-server
では受信周りの処理が以下のようになっているようです。
```
# Return
# - a received string
# - :timeout
# - :exception
# - nil when a socket is closed
#
def gets_safe(socket, timeout=nil)
if r = select([socket], nil, nil, timeout)
return r[0].first.gets
else
return :timeout
end
rescue Exception => ex
log_error("gets_safe: #{ex.class}: #{ex.message}\n\t#{ex.backtrace[0]}")
return :exception
end
```

通常、この処理で60秒間受信が無かった場合は:timeoutを返し、時間切れの検出処理等を行っているようなのですが、これがテスト版4で対局が行われた際には60秒おきに空行を受け取り続けていたため、なかなか:timeoutが発生せずに時間切れの処理に入れていなかったと見られます。

1095．Re: テスト版３での不具合例
名前：Mizar    日付：2020/10/1(木) 11:57
カツ丼将棋さんによると、このshogi-serverの:timeout発生間隔を60秒から29秒に変更し試してみるとの事です。

1096．Re: テスト版３での不具合例
名前：カツ丼将棋    日付：2020/10/1(木) 12:33
Mizarさんの書き込みにあります通り、事象の原因がはっきりしました。
電竜戦サーバ側のDefult_timeoutを60秒から28秒にしたところ、すべてうまくいきました！

本件について、我々としてはこの対応で困ることはありません。
ただfloodgateを始めとしたほかのshogi-server側の設定がどうしているかわからないところですが、KeepAliveをDefault_timeoutと同じ設定にすると不安定になってしまうわけですが、クライアントの設定がどうであれ、サーバ側がタイムアウトを検知して送信すべきことですので、shogi-server側の開発者様に状況を報告しておきます。

1099．Re: テスト版３での不具合例
名前：Mizar    日付：2020/10/19(月) 21:1
https://osdn.net/projects/shogi-server/ticket/40821#comment:1877:40821:1601821869

shogi-serverのプロジェクトの方に報告はしていますが、テスト版4での「半角空白＋改行文字」を定期的に送る動作に対する対策と対応はまだされていないようです。（時間切れ負けで着手放置が続いた際、テスト版４でのKeepAliveが行われていると対局サーバが時間切れを検出できず、永遠に対局状態が続く可能性がある）

一応、floodgateにテスト版4で接続する際には注意が必要かもしれません。
1091．USIプロトコルのscoreについて確認 返信  引用 
名前：４８    日付：2020/9/29(火) 22:1
テスト版４の対応ありがとうございます。
AGREE切れ以外の状況はリカバーできていることを確認しました。
次回大規模夜戦で問題なければ電竜戦に耐えれると思います。

ところで，テスト中にちょっと不思議なことがあったので確認させてください。
後手番の終盤でエンジン側が以下の４行を送りました。自作エンジンです。
info depth 1 time 12 nodes 2687 nps 223916 score cp 721 multipv 1 pv 1b1c B*2b 1c1d
info depth 2 time 71 nodes 15860 nps 223380 score cp -32000 multipv 1 pv
info score cp -32000 pv 1b1c string random
bestmove 1b1c ponder B*2b

１行目は読みが浅く自分側がやや有利と思っていますが２行目で負けを読み切ります。
雑な管理なのでPVが出ていません。
３行目は負けを読み切った際でも詰み局面まで指すために合法手をランダムで選んでいるところで，４行目は着手です。

以上の４行で２行目か３行目のscore cp -32000が採用されると思っていたのですが将棋所のグラフ上でもfloodgateへの送信評価値も１行目の721を送っているようです。
これは私の理解が足りないのでしょうか。理由がわかれば教えてください。


1093．Re: USIプロトコルのscoreについて確認
名前：将棋所の作者    日付：2020/9/30(水) 23:20
報告ありがとうございます。最近ちょっと忙しくて、なかなかすぐに回答できません。これから調べてみるのでしばらくお待ちください。

1097．Re: USIプロトコルのscoreについて確認
名前：将棋所の作者    日付：2020/10/3(土) 23:6
調べたところ、両方とも盲点みたいなことが原因になっていました。以下ちょっと説明が長くなります。

まず、２行目の評価値が採用されない問題について。
将棋所でエンジンの思考情報を表示する部分は、予想手・現在の探索手・探索局面数などを表示する部分があり、その下に、読み筋ごとの思考時間・探索深さ・探索局面数などをリスト項目で追加して表示する部分があります。
この、リスト項目の部分は、現状の将棋所では、読み筋がない場合は追加しないようにしてあります。その場合、探索深さや探索局面数は上記の表示部に表示できるし、読み筋のない項目をリストに追加しても意味がないと判断しているためです。
ただ、評価値に関しては独立した表示部がないので、表示するのであれば、必ずリスト項目の部分になります。なので、リスト項目に追加されない行の評価値は表示されません。
つまり、２行目のように読み筋がなくて評価値のある情報を返した場合、将棋所ではその行の情報をリスト項目として追加しないので、その評価値が保存されず、グラフ表示にも採用されません。エンジンが手を指したとき、もし、その評価値を採用してグラフに表示すると、それを見ている側からすると、どこにも表示されなかった評価値が突然グラフに表示されて、この評価値はどこから来た？ということになります。
送っている評価値が採用されないのはおかしいという意見ももっともなので、読み筋がなくてもリスト項目に追加して表示するか、あるいは評価値にも独立した表示部を設けるという方法もありますが、どちらもちょっと気の進まないところがあります。

次に、３行目の評価値が採用されない問題ですが、これはmultipvを使う行と使わない行が混在することが原因でした。
１行目でmultipv 1を使っていますが、この場合、将棋所では、multipvの数字ごとに、それに対応した読み筋と評価値を保存します。multipvの数に応じて読み筋が複数存在する可能性があるので、エンジンが手を指したとき、その手と初手が一致する読み筋を探して、それに対応する評価値をグラフ表示などに使うためです。
その後、３行目でmultipvを使わずに読み筋を返すと、この行の評価値は、multipvの数字ごとに保存する部分とは別に保存されるのですが、そのあとで手を指すと、将棋所ではmultipvの数字に対応した評価値を先に見に行ってしまうので、３行目で返した評価値が無視されていました。
これに関しては、multipvを使わない行での評価値がmultipvの行よりもあとに返って来たなら、それを優先して表示すべきかもしれません。ただこれも、同一局面の思考表示において、multipvを使う行と使わない行が混在すること自体どうなのか、ということがあります。
（別の話ですが、infoコマンドを返す時、同じ行の中でpvとstringを同時使用するのは規約違反です。USIプロトコルの解説にも、「pvとstringの同時使用は不可」と明記してあります。今回の問題とは関係ないのでこれ以上触れませんが）

以上、将棋所の問題と言えばそうなのですが、エンジンの返すコマンドの使い方がかなり想定から外れていて、それに対する動作として大きな欠陥があるとも思えないので、修正すべきかどうか迷っています。

1098．Re: USIプロトコルのscoreについて確認
名前：４８    日付：2020/10/4(日) 9:22
調査ありがとうございます。
こちらとしては対応できる情報を頂けたので十分です。
実装が見えないと原因を推測するのが難しいなと言ったところです。

選手権などでも妙なグラフを描いてる部分などがあるように思っていたので
これを機に確認することにします。
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も検討したいと思います。
ページ： 1 2 3 4 5 6 7 8 9 10 >> >| 

無料アクセス解析

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

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