[過去ﾛｸﾞ] ふらっと C#,C♯,C＃（初心者用） Part141 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
325(1): 2020/03/04(水)09:15 ID:TuAQ3w56(1/16) AAS
プログラミングそのものの話ではないんですが、c#で他の機械とソケット通信してデータやり取りしてこちらからの指示やその応答でなんらかの処理を行うプログラムはどう作るのが一般的なのでしょう？
通信を行うプログラムと業務用にオペレータからの操作とその他を担うプログラムにわけて作ろうと思っています。
通信相手はIOTのマイコンのようなもので独自のプロトコルがTCP/IP上で規定されています。
通信プログラムと業務用のアプリのデータのやり取りはファイルとしてデータを保存するのも手ではあるのですが、読み書き遅いので、共有メモリ的な使い方とかメッセージ的な使い方にならないかな、と。
linux上でc言語ばかり使っているので、どうするのが一般的なのかよく分かっておりません。
よろしくお願いします。
327: 2020/03/04(水)09:51 ID:TuAQ3w56(2/16) AAS
>>326
ありがとうございます
通信相手はIoTの小さなマイコンでOSはありません
329: 2020/03/04(水)10:18 ID:TuAQ3w56(3/16) AAS
>>328
わかりにくくてすいません
二つあって、ソケット通信するプログラムと業務用のプログラムを分けて作る場合の普通の作り方です
ソケット通信するプログラムは言語に付属してるライブラリをそのまんま使うしかないなと思ってます
プロトコルは規定されてるのでうまく作れないならcで作るしかないかな、と
業務用のアプリとソケット通信するプログラムのIPCはc#でどうやるのがWindowsの流儀なのか、お尋ねしております
ご教示いただいたgRPCは後者についての情報ですね
はじめて聞く技術なのでわかっておりませんが、参考とさせていただきます。少し道具立てが大きそうですね
ありがとうございます
332: 2020/03/04(水)10:36 ID:TuAQ3w56(4/16) AAS
>>330
普段はlinuxでc言語ばかり使っています
Windowsでc#を使うことがなかったので、どういうものが普通とされているのか分かっておらず、戸惑っております
333: 2020/03/04(水)10:37 ID:TuAQ3w56(5/16) AAS
>>331
IPC的なものは使わずにソケット通信すると言うことですか。なるほど。
336: 2020/03/04(水)11:18 ID:TuAQ3w56(6/16) AAS
>>334、335
わかりにくくてすみません
IoTデバイスとの通信はTPCIP上で独自のアプリケーションプロトコルが規定されてて、それに従います
それをやる通信用のプロセスと別建ての業務用のプロセスの間でもデータのやりとりを行う必要があるのですが、IPCはどうやって普通は実現してるのかがC#を使う上でわかっておりません
338: 2020/03/04(水)11:58 ID:TuAQ3w56(7/16) AAS
>>337
他にも組み合わせて使うと思いますが、その通りです。
339: 2020/03/04(水)12:31 ID:TuAQ3w56(8/16) AAS
ど素人め、定番はこれだって回答がすぐにないのは
ひょっとすると、プロセスごとにわけて機能を作り込むような考え方はWindowsというかC#というかわからないですが、一般的ではないのでしょうか？
341(1): 2020/03/04(水)13:05 ID:TuAQ3w56(9/16) AAS
>>340
私の書いた文はわかりにくいかもしれませんが、そのご指摘はどういう意味なのでしょうか？
345: 2020/03/04(水)14:38 ID:TuAQ3w56(10/16) AAS
>>342
なるほど
>>343
おっしゃることはよくわかります
抽象的でフワフワしてる質問であることも承知しております
その上で、デファクトスタンダードというかどこでもこんな方法よく使ってるよというご意見があればと。
手法についてご教示ありがとうございました
>>344
そうですね
一度使い始めると、それなりに長い寿命のソフトになってしまうので、悩ましいところです
省3
347(1): 2020/03/04(水)18:01 ID:TuAQ3w56(11/16) AAS
>>346
ははは
そう解釈されましたか
識者「ど素人め、定番はこれだ」
私 なるほどー
という意味で書いたのですが、誤読を誘発してしまいましたね
私が他者へど素人めと言ってるわけではなく、識者ならこんなフワフワした質問は、パッと答えてくれるかなと思って書いたのです
350(1): 2020/03/04(水)18:32 ID:TuAQ3w56(12/16) AAS
>>349
機能が違うのが一番の理由です
設計するにあたって、通信の機能は独自のプロトコルがあるのでそれなりに考慮しなきゃいけないことが多くて、通信に専念させたいのですね
業務用のプロセスは、こちらはこちらでＵＩがありますので、通信を行う機能とは考察しなきゃいけないところが違います
また、両者の動作タイミングが全く違うこともありますね
352(1): 2020/03/04(水)18:49 ID:TuAQ3w56(13/16) AAS
>>351
動作タイミングが違いますので、dll化では実現できないと考えています。
一つのプロセスで実現するにはマルチスレッド化せざるを得ないと思うのですが、そうすることは暗黙でみな承知している事柄なのでしょうか？
マルチスレッドでもマルチタスクでも似たような考察点はあるのでどちらを採用しても作成する難易度は大差ないのだとは思いますが、知識が余りに不足しており、マルチスレッドスレッド化したプロセスのデバッグは私では困難極まりないとも考えています。
356: 2020/03/04(水)19:08 ID:TuAQ3w56(14/16) AAS
>>353
ありがとうございます
考え方ですね
勿論、通信と業務双方まとめて考察できてモノシリックな作りに出来たらそれはそれで良いのだと思います。
通信機能は状態遷移に従って色々やらせる事があるので、業務用の機能と合わせて考察するのは、私にはなかなか難しいのです。
ちなみに、可能でしたらご教示頂きたいのですが、マルチスレッドのプログラムのデバッグ手法はどのようなものでしょうか
webや良書など、参考にされたものがありましたら教えていただけませんでしょうか
省3
357: 2020/03/04(水)19:12 ID:TuAQ3w56(15/16) AAS
>>355
ありがとございます
それはその通りです
機能ごとに作るのは、仰っている接点をキチンと作ることでもあります。
通信した結果をなんらかのIPC機能を使って業務用のプロセスに通知、逆に業務用のプロセスからの指示を通知するように明示しておきたいのです
一種の責任分界点としての役目もありますね
362(1): 2020/03/04(水)19:30 ID:TuAQ3w56(16/16) AAS
>>358
親子関係は特に考えていませんね
24時間運用することを想定してます
業務用のプロセスはデバイスの稼働状況とセンシングしてるデータのモニタリング、及びそれらの蓄積。
必要に応じてデバイス(のさらに先にいる装置)に対してある種の指示を行うことを想定してます。
センシングしてるデータはそのまんまではなく、モニタするときには簡単な加工(FFT程度)して表示させるつもりです。
業務用のプロセスは、可能だったらポーリングではなく、イベントドリブンな形で受信を契機に即座に表示してほしいのです。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.034s