---

[79] Re:[78] [77] [76] [75] [74] TFTのIPv6接続での利用について 投稿者：PANDA 投稿日：2021/08/08(Sun) 16:53

IPv4 アドレスによる接続の場合に任意のポート番号で「接続要求を待つ」ことができないという問題は、IPv6 アドレスによる接続の場合には影響しないと考えました。
そのため、任意のポート番号を指定できるようにする代わりに、 IPv6 アドレスでも接続できるようにしたバージョンを 0.13 として公開しました。
今回のアップデートにより、問題は解消されましたでしょうか？

---

[78] Re:[77] [76] [75] [74] TFTのIPv6接続での利用について 投稿者：むら 投稿日：2021/05/26(Wed) 22:55

> ちょうど今、「接続要求を送る」側にも影響する制限であった場合に備えて、
> 「接続要求を送る」際のローカルポートとリモートポートの両方を
> 「接続要求を待つ」側が開放可能なポートと同一に設定するというバージョンを
> 試作していたところでした。

なんともう試作に取り掛かられていたのですね
貴重なお時間を取らせてしまったようで申し訳ありません。

任意のポート番号を開放できないという問題は、
決まったポートの開放が必要な一部のゲームやアプリ等でホストになれないなど支障があるようです。
去年頃からプロバイダ各社も「夜間の混雑を避けられる」とか、
「オンラインゲームが快適になる」などの謳い文句で、
続々とIPoE方式でのサービスを開始しているようです。
少し前までは「IPv6の普及なんて何年かかるんだか」なんて思っていましたが、
結構もうすぐそこまで来ているかもしれませんね。

---

[77] Re:[76] [75] [74] TFTのIPv6接続での利用について 投稿者：PANDA 投稿日：2021/05/26(Wed) 20:13

おお、開放可能なポート番号の問題でしたか。

> このタイプだと開放可能なポートが240個割り振られるのですが、
> 与えられるポート番号自体は勝手に決められる上に、
> 契約している間は変更もできず固定なので、
> 今回の私のように9999-10000番がもらえなかったらポート開放不可という事態になります。
> 仮に双方ともに接続方式がIPv6だったとしたらTFTは使えなかったと思います。

いやぁ、ポート番号を自分で選べない時代が来るとは思いもしませんでしたよ。

ちょうど今、「接続要求を送る」側にも影響する制限であった場合に備えて、
「接続要求を送る」際のローカルポートとリモートポートの両方を
「接続要求を待つ」側が開放可能なポートと同一に設定するというバージョンを
試作していたところでした。

もしそんな窮屈な制約が存在していたら、様々なクライアントプログラムに影響が
出るのを避けられないだろうなと思いつつ。結局、「接続要求を送る」側には
影響しない制限だったということで、ホッとしました。

> ここからは私の勝手な提案ですが、もし今後、TFTをアップデートされる機会がありましたら、
> 使用するポートをユーザーの任意の番号に変更できるようになると、
> 今後増えるであろうIPv6（IPoE）方式で開放できるポートに制限がある環境でも
> TFTを使いやすくなるのではと思います。

提案ありがとうございます。

---

[76] Re:[75] [74] TFTのIPv6接続での利用について 投稿者：むら 投稿日：2021/05/26(Wed) 19:16

早速の返信ありがとうございます！
結論から申し上げますと、根本解決ではないかもしれませんが状況は改善しました！

> 一般論として「ポート開放」はサーバとして動作する側の話ですので、
> むらさん側が「接続要求を待つ」を選択する場合にのみ関係する話であると思われます。

PANDAさんのこのメッセージからヒントを得て、
これまでは私が「接続要求を待つ」役目でしたので、
相手（IPv4）に9999-10000のポート開放をしてもらい、
セキュリティソフトのファイアウォールの監視からTFTを除外してもらった上で
相手のグローバルIPを接続先として接続要求を送ってみたところ接続できました！
もちろんファイルの交換もうまくできました。本当にありがとうございます。
私がIPv6になったことで転送速度も大きく改善し、相手の友人も大変感謝しておりました。

IPv6におけるポート番号の話ですが、私が利用している「v6プラス」というサービスは、
MAP-Eという通信技術を使用しています。（IPoE方式の中でたぶん一番主流です）
このタイプだと開放可能なポートが240個割り振られるのですが、
与えられるポート番号自体は勝手に決められる上に、
契約している間は変更もできず固定なので、
今回の私のように9999-10000番がもらえなかったらポート開放不可という事態になります。
仮に双方ともに接続方式がIPv6だったとしたらTFTは使えなかったと思います。

ここからは私の勝手な提案ですが、もし今後、TFTをアップデートされる機会がありましたら、
使用するポートをユーザーの任意の番号に変更できるようになると、
今後増えるであろうIPv6（IPoE）方式で開放できるポートに制限がある環境でも
TFTを使いやすくなるのではと思います。
よろしければご検討いただければ幸いです。

PANDAさんがくださったヒントのおかげで今回の問題を回避できました。
今後ともTFTを愛用させていただきます。本当にありがとうございました！

---

[75] Re:[74] TFTのIPv6接続での利用について 投稿者：PANDA 投稿日：2021/05/26(Wed) 00:09

こんにちは。

この問題を解決するには何往復かの質問や実験が必要になると予想します。
頻繁にこの掲示板をチェックしていただくというのも手間でしょうし、
グローバルＩＰアドレスやポート番号などの情報を公開の場所に書き込むのは
クラッカーに対して「私はここにいるので攻撃してください」と発言するようなものです。
ですので、今後のやり取りはメールでも構いませんよ。

> 相手は通常のPPPoE方式で利用されていて、
> こちらがIPoE方式だと接続は不可能なのでしょうか？

私は同じ環境を用意できない（ TFT を LAN 環境内でのみ利用している）ので、
インターネット環境で使用する場合の制約に起因した問題については回答できません。

> また、このサービスはポート開放は予め割り振られた範囲内のポートしか開放できず、任意の番号のポートを開放できません。
> TFTで使用する9999-10000番は残念ながら私に割り振られた範囲にはありませんでしたので、その番号のポート開放ができません。
> それも関係ありますでしょうか？

一般論として「ポート開放」はサーバとして動作する側の話ですので、
むらさん側が「接続要求を待つ」を選択する場合にのみ関係する話であると思われます。

とりあえず、むらさんの環境と相手の環境の両方で開放可能なポート番号を２つ提示していただければ、
9999 と 10000 の代わりにそれらのポート番号を使うようにしたバージョンを試作することができます。
それを相手と共有して実験することで、開放可能なポートが制限されていることが影響しているかどうかを
切り分けることができるものと考えます。

---

[74] TFTのIPv6接続での利用について 投稿者：むら 投稿日：2021/05/25(Tue) 20:31

はじめまして。長年TFTを愛用させていただいています。

IPv6接続でのTFT利用について質問させてください。
先日プロバイダを変更しまして、接続方法が今までのPPPoE方式からIPoE方式に変わり、IPv6での通信がメインになりました。
方式が変わったことでオンラインゲームや動画視聴は快適になったのですが…
TFTでのファイルのやりとりができなくなってしまいました。
相手のグローバルIPを接続先に入力しても繋がらないのです…
通信設定を変更して、一時的にIPv6の機能を停止してIPv4接続すると以前のように接続することができます。
相手は通常のPPPoE方式で利用されていて、
こちらがIPoE方式だと接続は不可能なのでしょうか？

環境ですが、私も相手もOSはWin7を利用しております。
相手側は普通のPPPoE方式でのネット接続を利用しています。
私が契約しているIPoE接続サービスは「v6プラス」という、通信方式がMAP-Eのサービスです

また、このサービスはポート開放は予め割り振られた範囲内のポートしか開放できず、任意の番号のポートを開放できません。
TFTで使用する9999-10000番は残念ながら私に割り振られた範囲にはありませんでしたので、その番号のポート開放ができません。
それも関係ありますでしょうか？

ネットワーク関連の知識に疎く、おかしなことを書いていたら申し訳ありません。
よろしければご返信いただければと思います。よろしくお願い致します。

---

[73] 無題 投稿者：yamanouchi 投稿日：2020/11/23(Mon) 21:27

ソフトウェアに32bit版64bit版などがある事を考えればそこに思い至る事も可能だったはずですが無知の限りで反省しきりです。
テスト版を此方でも試そうと思ったのですが、ちょうどバックアップ用HDDの寿命が尽きて大きなファイルが手元に無く無為に過ごしておりました。
アップデートしていただき本当にありがとうございます。
今後とも長くお世話になります。

---

[72] Re:[71] [70] [69] [68] [67] はじめまして 投稿者：PANDA 投稿日：2020/11/15(Sun) 23:21

３２ビットとか６４ビットとかいう言葉を聞いたことはありますよね？４ＧＢというのは３２ビットで扱えるサイズの上限なのです。
そのため、４ＧＢという上限を超えるためには、３２ビットで作られていた部分を６４ビットで作り直すという内部構造の変更が発生するのです。

（情報を探すのに苦労しましたが） Visual Studio 2019 でも Windows XP 向けのプログラムをコンパイルできたことと、手元に VMware 上で動作する Windows XP 環境が残っていたという幸運とが重なって、 Windows XP 以降に対応したバージョンとして作成することができました。

---

[71] Re:[70] [69] [68] [67] はじめまして 投稿者：yamanouchi 投稿日：2020/11/10(Tue) 19:40

ありがとうございます。
ソフト作成に疎い者が「上限の数字を変えるだけなら簡単かな」と安直に要望を出してしまった結果、大事になってしまったようで恐縮至極です。
とはいえ愛用ソフトのアップデートという事でとても楽しみにしています。

素人考えですが、ネットニュースなどでサポート期限切れOS使用率が意外と高い印象があるので、OS普及率の高いWinXP・Win7・Win10のいずれか以上という区切りが良いように見受けられます。
また、昨今は検索エンジンでTFTを発見しにくい状況ですので、バージョン情報に「製作者URL」の表記があると布教活動が捗ると思います。

---

[70] Re:[69] [68] [67] はじめまして 投稿者：PANDA 投稿日：2020/11/09(Mon) 21:14

> TFTは他者に導入してもらいやすくファイル毎の成否ログがありなおかつ動作が軽い、個人間ファイル送受信ソフトとしては現在でも圧倒的優位にあると私は感じています。

なるほど。 Windows にランタイムライブラリを追加することなく動かせるというのが強みということですね。それなら、 Win32 API だけで動くという現在のアプローチを継続した方が良いですね。
当時は Windows 95 でも動かせるようにするために、利用する API を限定していましたが、現在では Windows 8.1 以降を前提として良さそうなので、比較的新しい API でも利用できますね。

とりあえず、 Visual Studio 2019 で x86 および x64 向けにコンパイルできるところまでアップデートしました。これから、細かいところをチェックしながら、４ＧＢ以上のファイルを扱えるようにする方法を考えてみます。

---

[1] [2] [3] [4] [5] [6] [7] [8]