開発ノート (91)

川内 康雄

Unityでワンソースなシステム開発:UnityでManualResetEventとかwhileループとかを使うと固まる

MSDNのTCP非同期サーバーのサンプルコードをUnity上で動かそうと移植していたら、Unity自体が固まって強制終了せざるを得なくなるという現象が発生。ロジックを追っていくとまずwhileの無限ループがあると固まることが判明。開発環境上でPlayするときはアプリは別スレッドで動かしてくれたらいいのにと思うのですが。何か理由があるんでしょうかね。でwhileを抜いて実行してみてもやっぱり固まる。今度はManualResetEventでWaitOneしているときに固まることが判明。もちろんSetされたら復活するのですが、その間停止するのはアプリとして問題ですから使わない方がいいですね。今回のコードではManualResetEvent自体が不要そうなので丸ごと消しましたが、どうしても必要な場合はスレッドを作った方が良さそうです。 public static ManualResetEvent allDone = new ManualResetEvent(false);// Set the event to nonsignaled state.allDone.Reset();// Wait until a connection is made before continuing.allDone.WaitOne();// Signal the main thread to continue.allDone.Set(); “”” 停止する原因は、Unityのメインスレッド上で無限ループやWaitOne()による待機を続けることです。ManualResetEvent自体が常に使えないわけではありません。ワーカースレッドで待機する設計も可能ですが、多くのUnity APIはメインスレッドから扱う必要があるため、受信結果の反映方法も分けて設計します。

Continue reading...
川内 康雄

// Use this for initialization

仰々しいタイトルですが、要は同期+スレッドと非同期のどちらがいいのかという話しです。「C#でTCPサーバーの実装を作ったよ」というレポートはかなり多くて、www.codeproject.comなんかで検索すると10件近く出てきます。日本語の情報もいくつかあり、チュートリアル的な情報では、まずは同期式で勉強してから非同期でという流れが多いですね。Unityを始めてまず「オンラインゲームのしくみ」を読んだのですが、この本の場合は非同期で作るのは大変だから同期でつくろうよというスタンス。この本のライブラリを使ってコーディングを始めたのですが、このライブラリが複数接続に対応しておらず、結局作り直しになりました。で、色々と見て回ったところ同期ベースか非同期ベースかというところで大きく分かれているので、自分はどちらでいこうかと迷い、メリット・デメリットを検討してみました。で、同期の方のメリットは、結局、スレッドプログラミングになれている場合には、プログラムの構造がわかりやすい、つまり書きやすいというところに尽きるようで、他のメリットは見あたりませんでした。僕の場合、マルチスレッドは使ったことが無いのであまりメリットは感じられず、スレッドがメモリを食う、オーバーヘッドが大きいというデメリットの方が大きく感じました。サンプルコードを見ていると、非同期式でもそれほど複雑なプログラムにはならなさそうなので、非同期で実験してみることにしました。で、MSDNのサンプルコードを使ってUnity上でTCPサーバーを非同期で実行するためのサンプルがこちら。いわゆるチャットサーバーですね。いくつかはまりポイントがまたありましたが、概ねスムーズに書けました。ncコマンドで複数の端末から接続すると、それぞれに固有番号を振った上で、ある端末のメッセージが全端末に送信されます。接続切断はまだ未実装です。ちょっと困ったなと思うのはどうにもコードが肥大する感じで見にくいです。クラス化しようかと思ったのですが、コールバックはビジネスロジック側で実装しないと意味が無くて、サイズを取っているのがコールバックなので、クラスにしてもあまり意味が無い感じがしました。デリゲートで作れるとは思うのですが、このあたりはまだ慣れていないので余力があれば書こうと思います。 // There could be Copyright (c) of Microsoft and Yasuo Kawachi// If there is, this code is licensed under Microsoft Limited Public License// https://msdn.microsoft.com/en-US/cc300389 See ""Exhibit B""// I belive there is no copyright due to non creativityusing UnityEngine;using System.Collections;using System;using System.Net;using System.Net.Sockets;using System.Text;using System.Threading;using…

Continue reading...
川内 康雄

Contact Form 7のスパム対策

このサイトのメールフォームはContact Form 7を使用しています。導入した直後からスパムが送られてきたのでReally Simple CAPTCHAを組み合わせて使っていました。が、ここ数日このキャプチャを乗り越えてくるスパムが続発。体裁が同じなので同じボットだと思います。某調査によればアルファベットのキャプチャはOCRを使って「人間よりも高い精度」で読み取り可能らしいので、仕方ないですね。で、こちらのサイトさんの手順を参考にして、認証をキャプチャからクイズに変更しました。アホらしい質問ですが、これに答えられるボットはそうそういないでしょうから、しばらくはこれで耐えられるのではないかと思います。”””

Continue reading...
川内 康雄

CH340/CH341のドライバインストール

CH340/CH341を使用したUSB-シリアルチップを使用したかったので、公式サイトから、CH341SER_MAC.ZIPをダウンロードしてきました。各所で配布されているようですが、公式からでないとなんか不安ですね。セキュリティ許可が必要というのはマニュアルにも書いてあるのですが(中国語のPDF)、Yosemiteだとこちらにあるように、ターミナルからsudo nvram boot-args=””kext-dev-mode=1″”の実行が必要でした。再起動も必須のようです。””” 上記はOS X Yosemiteで試した当時の記録です。kext-dev-mode=1 は古いカーネル拡張向けの設定であり、現行macOSの導入手順としてそのまま実行するものではありません。WCH公式の対応OS別ドライバと導入手順を確認し、OS・CPUに合う版を使ってください。

Continue reading...
川内 康雄

電波法に準拠した電波暗室を自分で作ることはできるのか(失敗作の例)

ESP8266の実験用にebayでNode MCUを購入したのですが、このモジュールは国内で販売されているものと違い、TELEC認証(技適マーク)がついていません。そのためこのまま電波を発射すると電波法違反になってしまいます。それでは流石に職業上マズいので、合法的に使用できないか考えてみました。一つは送信電力を弱めて微弱無線局にする方法。ただネットで調べていると、1.2GHz帯で微弱無線の送信出力にしようとすると、送信側、受信側のアンテナが接する距離しか取れないとのこと。http://www.eleki-jack.com/archives/images/Elc02_030031_toku1AP.pdfhttp://www.circuitdesign.co.jp/jp/technical/technical_pdf/bijaku.pdf.PDFモジュールは2個あるので、出力設定を最小にして、パターンアンテナをぶった切れば何とかなるかと思ったのですが、23nWという微弱な出力とするのは困難ですし、距離1mmでも通信不可となると意味がありません。そこでもう一つの方法である電波暗室内で実験することができないかと考えました。電波暗室が法律上の電波暗室となり得る条件はこちら。http://www.tele.soumu.go.jp/resource/j/material/dwn/kouzi3.pdf要は40デシベルの減衰が実現できるシールドですね。こういった電波暗室はお金を払えば大規模なものが借りられるようですが、ちょっとした実験で都度レンタルするわけにもいきません。そこで電磁波のシールドをする袋をつくったらどうかと思いつきました。銅箔テープが余っているので、これをチャック付きポリ袋の表面に貼りまくったらシールドとして機能しないかという発想です。銅箔自体は-70dbぐらいの電磁波遮蔽能力があるようですので。EMC対策用の導電性メッシュが多く市販されているようですが、メーター単価で1万円近い値段がするのと、Amazonあたりで「電波が通る」というクチコミが立ちまくっているので、今回はとりあえずパスです。で、早速作ってみました。とりあえずiPhoneが入る大きさでの実験です。iPhoneをテザリングのアクセスポイントにして、Mac OSXのワイヤレス診断でRSSIを計測します。RSSIの変化量とシールドの減衰量は意味合い的には同じでは無いと思われますが、厳密な計測機器など持っていないので、まずはこれで実験です。この袋に入れない状態でのiPhoneの受信強度はこちら。袋に入れるとこの状態。単純計算でも15dbぐらいしか下がっていません。若干減衰したものの、十分に通信できる数値です。単純掲載でも3M法と言われるぐらいなので、3M程離してみたときの状態がこちら。これでもまだ通信が可能な数値です。2階の角のwifiアクセスポイントと同じぐらいの受信感度なので、残念ながら微弱電波と評価できるような出力にはなっていないと思われます。と思っていたら、タイミングよく、この袋の中で携帯が鳴り出しました。誰かが僕に電話をしてくれたようです。基地局と通信できるだけの出力があるということは、微弱無線な訳が無いですね。そんなわけで工作失敗ネタでした。せっかく買ったNode MCUモジュール使いたいのですが、なにかいい方法ないですかね−? “”” 当時の自作シールドが目的の遮蔽性能に届かなかった、という結論はそのままです。現在は、一定の技術基準に適合する技適未取得機器について、所定の届出をして実験等を行う特例制度があります。180日という期間制限等があり、未認証の機器ならすべて対象となるわけではありません。対象機器・周波数・実験の要件を総務省の案内で確認してください。

Continue reading...