HSPTV!掲示板

またスレッドを立ててしまってごめんなさい。
ここ
http://sky.geocities.jp/f_the_darudaru/manaita/index.html
にあるaskを昨日DLさせていただいて、早速スクリプトを作りましたが、またもや奇妙な現象が発生しました。
以下に内容をまとめます。
　まず、サーバ・クライアントプログラムをサンプルからほぼそのまんま引っ張りテスト。外部からの接続不か。localhostでは問題なし。
友人にクライアントを渡して、接続をしてもらおうとしたが、接続不か。
つぎに、NAT割り当てが正常に動作しているかを確かめるため、主導でDLL内の関数を使ってポート開放の割り当てを行った。
そのあとで先ほどの接続テストをしたが、接続不か。
思いつきで、
http://www.cman.jp/network/support/port.html
このサイトを使ってポートにアクセスしようとしてみた。すると、なんとサーバ側のaskが反応。指定ポートに到達できたとのメッセージがサイトより出力された。
とりあえずNATはちゃんとできてるっぽいのだが、なんでつながらないのだろうというのがこんかいの疑問点です。
localhostでの接続がうまく言ってるので、こんかいはスクリプトは張りませんが、必要ならすぐに張ります。
気になったことなどありましたら、ご指摘をおねがいします。

・念の為だがファイアウォールは？
・付属サンプルのチャットサーバ起動した時、「グローバルIP」は取得できているか？
・ハンドル作成の際、ポート自動解放モードにしているか？

まずはこの辺か。

現在はAVGにはファイアウォールがないのでwindows標準のがオンになっています。しかし、ブロックとか許可とかはでませんでした。あとでこれをオフにしてやってみます。
グローバルIPは、取得できるときとできないときがあります。取得できるときは14という値が戻ってきて、できないときは失敗(0)が戻ってきます。
ポート開放は今現在はaMANUALでハンドルを作ってサーバ立てたあとにaIGDAddPortMappingを使って開放しています。これは成功します。

＞グローバルIPは、取得できるときとできないときがあります。
＞取得できるときは14という値が戻ってきて、できないときは失敗(0)が戻ってきます。

○int size = aIGDGetExternalIPAddress( int bufferSize , sptr externalIP )

それは14文字有るという返答で、実際にグローバルIPを受け取る文字列変数を
あてがうと取り出せるだろう。

globalIP=""
ret = aIGDGetExternalIPAddress( 64 , globalIP )

で、変数globalIPにIP文字列が取得できる。
グローバルIPが取得できている以上、askは正常にルータと通信している。

＞ポート開放は今現在はaMANUALでハンドルを作ってサーバ立てたあとに
＞aIGDAddPortMappingを使って開放しています。これは成功します。

○result = aIGDInitialize( int mxTime , int waitTime )

で初期化しているか？

＞取得できるときとできないときがあります

という事は、ちゃんと初期化が完了しているか

○int result = aIGDIsReady()
○int result = aIGDIsSearching()

辺りで確認しているか？



後は、

サーバを立てる時、
○bool result = aServer( int handle , sptr sessionName , sptr portNo , int msgMode )

ポート番号も「文字列」の指定なのに気付いているか？


クライアントがサーバに接続する時、
○bool result = aConnect( int handle , sptr ipNo , sptr portNo , int msgMode )

IP,ポート番号は「文字列」の指定だが、変数の型は合っているか？


この辺りか。

なんか、マニュアル見たら、
「sptr」とだけ書いてあって「文字列」と言う表現が書いてなかったな。

もしコレが原因ならすまん。
そのうち直しとく。

グローバルIPについては説明不足でした。IPはとってあって、14がサイズであることをマニュアル全部読んだのに抜かしてました。
最初sptrだったからポートに数値型変数をいれたらシステムエラーが起こったので、文字列に直してあります。クライアント側も直しました。
○int result = aIGDIsReady()
○int result = aIGDIsSearching()
この関数がマニュアルのナカに見当たりません。これはなにをするものですか?関数名の通り解釈していいのでしょうか?
あ、サイトに最新のマニュアルがあったらスンマセン。
クライアント側の接続をデバッグしてみると、クライアントループ-処理開始が2回表示されたあとに処理が終了しているみたいです。
接続成功とはでませんが、失敗とも出ないです。

＞○int result = aIGDIsReady()
＞○int result = aIGDIsSearching()
＞この関数がマニュアルのナカに見当たりません。

・・・・あ、いかん。すまん。
まだいじってる途中の未公開版の命令だった。
まじゴメン。

とりあえず、新しいのを早急にまとめてUPするので、夜まで待って欲しい。

わかりました。よろしくおねがいします。わざわざすみませんです。

更新した。
ただ、機能の習性部分だけなので
この質問の解決になるかどうかは別問題という事で。

チュートリアルにするつもりで作っておいたサーバサンプル

#include "Ask.as"
	sdim recvBuf , 1024
	handle = aCreateHandle( aAUTO )
	ret    = aServer( handle , "Server" , "59603" , aMSG_NONE )
	if ret = aFALSE : end
*recvLoop
	await 100
	if aGetTextLine( handle ) <= 0 : goto *recvLoop
	dpnid = aGetText( handle , 1024 , recvBuf )
	mes "DPNID [" + strf("%06d" , dpnid ) + "]:" + recvBuf
	if recvBuf = "やま！？" : ret = aSendTextTo( handle , dpnid , "皮！！" )
	goto *recvLoop

同クライアントサンプル

#include "Ask.as"
	sdim recvBuf , 1024
	handle = aCreateHandle( aMANUAL )
	ret    = aConnect( handle , "localhost" , "59603" , aMSG_NONE )
	if ret = aFALSE : end
	ret    = aSendText( handle , "やま！？" )
*recvLoop
	await 100
	if aGetTextLine( handle ) <= 0 : goto *recvLoop
	dpnid = aGetText( handle , 1024 , recvBuf )
	mes "DPNID [" + strf("%06d" , dpnid ) + "]:" + recvBuf
	goto *recvLoop

外部からアクセスするには

ret = aConnect( handle , "localhost" , "59603" , aMSG_NONE )

の "localhost" の所を

ret = aConnect( handle , "123.123.1.23" , "59603" , aMSG_NONE )

の様に、グローバルIPで書く。

ありがとうございます。
新しいのでやってみたら、以下のような結果でした。
サーバはもちろん動きました。しかしやはりクライアント側が外部から接続不か。
例のポートチェックを合わせて、ポートが開いてるかの実験。
aAUTO:つながらなかった
主導設定:つながらなかった（でもこれは私のせいかも）
旧バージョンで手動設定:ポートにはつながったらしい。でも、その状態で新しいクライアント側を実行した（接続だけならと思って）が、つながらなかった。
いろいろ難しいですね。考えられることはありますか？
さっきマニュアル見て書いた新バージョンのポート主導設定はこれ

ret=aIGDInitialize( 5,1)
repeat
if aIGDIsSearching()=aFalse:{
if aIGDIsReady()=aTRUE:break
}
wait 50
loop

あ、IGD開放を貼り残していたorz

あ
俺のせいだった
肝心な部分が抜けてた
その上に3回の連投
これはあとでちゃんと書きます。すみませんでした。

ポートは無事つながるようになりました。しかし、いただいたサンプルをクライアント側はまったくいじっていないのに祖父と終了=接続失敗…なんでなのでしょう…

＞ポートは無事つながるようになりました。しかし、いただいたサンプルをクライアント側はまったくいじっていないのに祖父と終了=接続失敗…なんでなのでしょう…

まず、外部からはサーバが起動してから４秒以上は待ってからクライアントを起動して欲しい。



状況整理

・ファイアウォールのブロックが表示されなかった->対処不明
・ローカルでの通信には問題ない
・ポートオープンには成功しているらしい
○外部からのクライアントのコネクトが正常でない
　ー＞成功か失敗か不明

まず添付のサンプルチャットソフトを例にする。
クライアントがサーバに接続する命令

ret = aconnect( handle , ip_no , port_no , aMSG_NONE )

のretには、接続に成功したかどうかの結果が入っている。

ので、接続成功したか失敗したか不明と言うことは無い。
確認して欲しい。

次に

bool result = agetFlagConnect( int handle )

で、接続状態にあるかどうかが判断できる。
確認して欲しい。


外部から接続する、そのマシンのファイアウォールが切れてないとか、無いじゃろうか。

いちお、友人のマシンアーンド回線、そして自分で自分のグローバルIPなんか入れてためしてみたりしましたが、接続は失敗でした。
if ret=aFalse:end
ここでソフトが終了しています。
たぶん、問題は接続するほうで確定ですね。

クライアント側のコネクトに失敗が原因だとはっきりしたが、
ちょっとその処理が失敗する理由となると困る。

ちと外部からの接続テストをやってみるが。

その友人側でサーバを立てて、自分側がクライアントでテストしてみるのはどうか。

ファイアウォールに既に「ブロック」で登録されてはおらんじゃろうか。
その場合、その設定を削除か修正の必用がある。

とりあえずサーバはちゃんとできてるっぽいので、いろんなPCから接続してもらってみます。
でも不思議なのは、こっちのファイアウォールにはすでに許可登録しているのに、こっちでサーバとクライアントを一緒に立てて、クライアントに自分のグローバルIPをしていしてもつながらないということです。
自分自身で自分自身のネットワークに外部から繋ぐこと自体が引かれている可能性もあるかもしれませんが、そこにはあんまり詳しくないので基本しかわかりません。

＞こっちでサーバとクライアントを一緒に立てて、クライアントに自分のグローバルIPをしていしてもつながらないということです。

それは繋がらんじゃろ。
グローバルIPはルータの向こう側のIPで、自分のPCのIPじゃない。

やっぱりそうなんですね。
ルー田側のIPにつながって、こっちのパソコン事態のIP(192.168.11.1）に転送されるかと思ってなかったわけじゃなかったので、実験していました。
やっぱりここからは一人で原因究明は無理そうなので、友人達に協力してもらって結果報告をここにします。

>それは繋がらんじゃろ。
>グローバルIPはルータの向こう側のIPで、自分のPCのIPじゃない。
一概には言えません。ルータによって繋がることも繋がらないこともあります。
ちなみに私は前者です。

＞一概には言えません。ルータによって繋がることも繋がらないこともあります。ちなみに私は前者です。

マジか。
覚えとこう。

調査しました。原因が分かりました。
まず、ask標準の

handle=aCreateHandle(aAuto)

はこちらの環境では正しく動かず、ポート開放は行われませんでした。
手動設定

ret=aIGDInitialize( 5,1)
repeat
if aIGDIsSearching()=aFalse:{
if aIGDIsReady()=aTRUE:break
}
wait 50
loop
localIP=""
globalIP=""
ret = aIGDGetCurrentIPAddress ( 64 , localIP  )
ret = aIGDGetExternalIPAddress( 64 , globalIP )
dialog "グローバルIPアドレスは、"+globalIP+"です。"
ret=aIGDAddPortMapping(localIP, "59603" , 1)
if ret=aTRUE:dialog "ポート開放に成功しました。"
ret=aIGDDisPose()
dialog "ポート開放ルーチンを通過しました。"

これを使うと正しく開放できました。
そして、クライアント側のcreateHandleの設定を「aManual」にしないとつながらないことが分かりました。
いろいろと知恵を貸していただきまして、ほんとうにありがとうございます。今度はチャットを自作してテストしてみます。

>handle=aCreateHandle(aAuto)
>はこちらの環境では正しく動かず、ポート開放は行われませんでした。

！
基本的には手動と同じ事をしているはずなんだが、そうか。
もっと詳しく調べてみよう。情報有難う。

>そして、クライアント側のcreateHandleの設定を「aManual」にしないとつながらないことが分かりました。

クライアント側はポート解放する必要ないからな。
念のため。

とは言え、繋がらない理由も分らんが。
これも詳しく調べてみる。
情報有難う。