製品を正しくインストールしアクティブ化もしたはずなのに「アクティブ化が必要」と表示される

弊社製品の V6 (およびそれ以前) のライセンスを新しいマシンに移行したお客様から時々このお問い合わせを頂くことがあります。

これは、新しいマシンが 64bit Windows OS の場合に発生します。ライセンスのアクティブ化情報はレジストリに格納されますが、Windows システムの都合で 32bit OS の場合と 64bit OS の場合で格納先が異なるためです。

これに該当する場合は、アクティブ化キー取得ページの URL の末尾に &w64=1 （全て半角 ASCII 文字でアンパサンドに続けてダブリュー、数字の６、数字の４、等号、数字の１) というパラメータを追加してアクセスします。例えば IP*Works! V6 .NET Edition の場合通常の 32bit OS 時は

http://www.nsoftware.com/download/lic.aspx?prod=ipn6a

ですが、これを

http://www.nsoftware.com/download/lic.aspx?prod=ipn6a&w64=1

とすることで 64bit Windows OS 用のアクティブ化キーを取得することができます。

Windows 以外の OS での Zip 自己展開形式サポート

弊社 Zip の .NET Edition では自己展開形式ファイルの作成をサポートしています (ZipSFX コンポーネント)。

このコンポーネントが生成するのは Windows の .EXE ファイルであり、Windows 以外の OS ではご利用いただけません。

なお、「OS に依存せず専用ツールなしで Zip を展開したい」ということであれば、.jar 形式を採用することでこれに近いことを行えます。(ただし Java ランタイムは必要。)

.jar 形式は、java -jar コマンドで展開可能ですので、Java ランタイムがインストールされている環境であれば OS に依存することなくまた専用展開ツールなしでアーカイブの展開を行うことができます。

EndTransfer イベントについて

あるお客様から、EndTransfer イベントの発生タイミングに関するお問い合わせを頂きました。

その内容は

・EndTransfer イベントが発生するのは、データ転送終了直後なのか、転送に関わる処理が終わった直後なのか

というものです。例えば弊社 IMAP コンポーネントで FetchMessageText() や FetchMessagePart() を実行した際に、fetch されたデータのプロパティへの書き込みは EndTransfer イベントが発生した時点で 終了しているのかどうか、ということです。

弊社の製品仕様では、EndTransfer イベントはデータの受信が完了した直後に発生しています。そして受信データから取り出した情報の各種プロパティへのセットはその後行われます。

従って、

・EndTransfer イベントは純粋にサーバとクライアント間でデータの転送が終わった事をのみを意味する
・転送されたデータのプロパティへの反映は、EndTransfer イベント内では保障されていない

ということになります。FetchMessageText() や FetchMessagePart() から制御が戻った時点では全てのプロパティ処理は完了していますので、プロパティ参照はそれ以降に行う必要があります。

tar ファイルのファイル末尾データについて (補足)

過去の記事で、EOA (End-Of-Archive) について述べましたが、今回はこれに起因する互換性の問題について述べてみたいと思います。

先の記事では、tar ファイルはその歴史的経緯からブロック化書き込みを行う必要があり、アーカイブの実データサイズとファイルサイズは必ずしも一致しないことを述べました。

しかし、実運用上はファイルの EOF (End-Of-File) を検出した時点で EOA を読み取ったのと同等の処理をする処理系が多く、弊社の tar コンポーネントも既定値では EOA を付与しないようになっています。

しかし弊社へのお問い合わせを見ていると、この EOA が必須となっている tar 展開プログラムも存在しているようです。(WinRAR 3.71 等。)

このような場合に対処するために、弊社の tar コンポーネントには ExtraNullBytes という構成設定項目が用意されています。

tar.Config("ExtraNullBytes=1024")

上記を行うことにより、生成される tar アーカイブの末尾に 1024 個の NULL 文字 (0x00) から成るブロックが付与され、EOA として機能するようになります。

FTPS で LIST コマンドがハングアップする

先日、あるお客様から FTPS でサーバに接続すると、サーバログイン後しばらくすると固まってしまう、というお問い合わせを頂きました。そのログを見ると以下のようになっています。

> Connecting to FTP server
> Connected.
> 220 Serv-U FTP Server v6.4 for WinSock ready...
> USER XXXXXXXX
> 331 User name okay, need password.
> PASS XXXXXXXX
> 230 User logged in, proceed.
> PWD
> 257 "/" is current directory
> PASV
> 227 Entering Passive Mode(192,168,0,2,8,71)
> LIST

サーバから 227 応答を得た後、クライアントが LIST コマンドを発行してところでハングアップしてしまいます。

これは、既定値ではパッシブモード時のリモートサーバアドレスを、サーバ応答から得るためで、この例ではリモートサーバはファイアウォールの内側に設置されており 192.168.0.2 というプライベートアドレスを使用しているためです。SSL を使用していなければファイアウォールがこのデータの書き換えを行ってくれるでしょうが、SSL で暗号化されたセッションの書き換えは行いません。この結果、クライアント側はサーバへのデータチャネルの接続にこのプライベートアドレスを使用してしまい、接続ができずタイムアウトしてしまうことになります。

これを解決するには FTP コンポーネントの構成設定パラメータで

    FTPS1.Config('UseRemoteHostAddressForPassive=true')

として、リモートサーバアドレスを RemoteHost プロパティから得るようにします。これにより、リモートサーバのアドレスは実際に当該クライアントから見たリモートサーバのアドレス (ファイアウォールのグローバル側アドレス) が使用されるようになり、ファイアウォールのポートフォワード機能を介して正しくファイアウォールの内側にあるサーバとコントロールチャネルを確保できるようになります。

IPv6 と IPv4

弊社の通信系コンポーネントでは、アドレス指定方式として IPv6 と IPv4 をサポートしています。

この設定は、UseIPV6 構成設定パラメータで指定します。既定値は false で、IPv4 アドレスを使用します。この設定を true にすることで、IPv6 アドレス形式を使用できるようになります。設定例 (C#):

コンポーネント名.Config("UseIPV6=true");

なお、UseIPV6 の設定の如何にかかわらずアドレス形式は IPv6 または IPv4 を排他的に使用します。両者の混在はできません。(UseIPV6=true の場合は IPv6 形式、false の場合は IPv4 形式のみがご利用頂けます。)

弊社製品で必要となる JDK バージョン

弊社 Java 製品は JDK 1.3 以降でのご利用を前提として設計されていますが、JDK 1.4 以降でのご利用をお勧めします。