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

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



1100.開始日時と棋戦につきまして 返信  引用 
名前:タッチ    日付:2020/10/25(日) 11:45
DB2の棋譜を貼ってコメントを上書きしたところ
開始日時と棋戦の情報が消えてしまいました
この2つは棋譜検索で重要な役割を果たしております
編集できなくてもよいので開始日時と棋戦の元情報を保持できるよう
ご検討お願いします(戦型もできれば)



1101.Re: 開始日時と棋戦につきまして
名前:将棋所の作者    日付:2020/10/26(月) 21:37
対局情報の保存については以前から何度か要望があって、いまいち必要性がわからなくて何もしていなかったのですが、そういう問題があるのなら、棋譜に元からある対局情報は保存するようにしようと思います。今すぐにはできませんがしばらくお待ちください。


1102.Re: 開始日時と棋戦につきまして
名前:タッチ    日付:2020/10/27(火) 14:4
お忙しいところ
早速のご返答ありがとうございます

$EVENT:(csa) 棋戦:(kif,ki2)
$START_TIME:(csa) 開始日時:(kif,ki2)
$OPENING:(csa) 戦型:(kif,ki2)

でそのまま変換保持していただけると
棋譜検索等で非常に助かります
お時間のある時で結構です ご検討していただけると幸いです

1075.テスト版3での不具合例 返信  引用 
名前:48    日付:2020/9/23(水) 10:46
常日頃お世話になっております。
また,テスト版3の作成ありがとうございます。
さっそく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: テスト版3での不具合例
名前:将棋所の作者    日付:2020/9/23(水) 23:45
確認ですが、切れ負けの場合というのは、サーバから#TIME_UPが送られてきて対局終了した、ということでしょうか(その場合、対局結果一覧を開くと、その対局のコメント欄には「時間切れ」と書いてあると思います)
あるいは、対局開始後、サーバから何も送られて来ない状態が続いて接続が切れてしまい、対局中のように見える状態が何時間もずっと続いたまま、ということでしょうか。
前者であれば、#TIME_UPが送られてきて対局終了した場合は再ログイン、というようにすれば対応できると思います。後者の場合、再ログインするきっかけになるイベントが何もないので、どのように再ログインするか、対策を考える必要があります。


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

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


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

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


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

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

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

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

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


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


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

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

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


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

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


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

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


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

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

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


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

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

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


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


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

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


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

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

一応、floodgateにテスト版4で接続する際には注意が必要かもしれません。

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

ところで,テスト中にちょっと不思議なことがあったので確認させてください。
後手番の終盤でエンジン側が以下の4行を送りました。自作エンジンです。
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

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

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



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


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

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

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

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


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

選手権などでも妙なグラフを描いてる部分などがあるように思っていたので
これを機に確認することにします。

ページ: 1 2 3 4 5 6 7 8 9 10 >> >| 

無料アクセス解析

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

   投稿KEY
   パスワード

EZBBS.NET produced by InsideWeb