問題タブ [select-function]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
2 に答える
402 参照

c - / dev /ttyUSB*が存在するようになったら開きます

私はコンピュータが稼働しているときに常に実行されるプログラムを持っています。USBデバイスを介してシリアルとインターフェースします。コンピュータの電源が入っているときに、デバイスが存在しない場合があります。

私の質問は、デバイスファイルが存在するようになったときに確認するための良い方法です。ファイルの名前がわかっていると仮定して、ファイルを継続的にチェックする無限ループを作成し、fdを取得するとファイルが中断する可能性があります。しかし、これよりも良い方法はありますか?

さらに、プログラムの実行中にデバイスのプラグが抜かれると仮定すると、私のfdは無効になります。これが発生したときに何らかのイベントまたはエラーがスローされるので、デバイスファイルが再び存在するまでチェックを再開できますか?

選択ループを使用してfdから読み取りました。

0 投票する
1 に答える
369 参照

c - Linux: stdin により、select が返されたくない場合に返されます

stdin に何かがある場合に select が返されるのは問題がありますが、それは望んでいません。たとえば、ソケット上のデータを一定時間待機するためのコードを次に示しますが、stdin にデータがある場合、select は次の値を返します。

0 投票する
2 に答える
3526 参照

c - cソケットプログラム-select()の問題

私はネットワークプログラミングに不慣れです。Cで簡単なクライアント/サーバープログラムを作成する必要があります。サーバーは接続をリッスンし、クライアントはサーバーに接続してメッセージを送信し、クライアントからエコーを受信します。サーバープロセスから同時に複数のクライアントへの接続を処理するには、select()を使用してこれを更新する必要があります。指示どおりにクライアント側でselect()を実装しようとしましたが、一部クライアント側で無限ループが発生していると思いますif(FD_ISSET(clientSockfd, &readfds))

これがサーバーです。

0 投票する
3 に答える
1554 参照

c - C ソケット - 選択時にブロック

select() 呼び出しを使用して複数のソケットをリッスンするクライアントサーバープログラムに取り組んでいます。しかし、それらのソケットの 1 つにメッセージがありますが、select() 呼び出しはそれを認識せず、無期限に待機しています。

プログラムには、マスターとクライアントの 2 つのエンティティがあります。マスターは、処理するクライアントの数を認識しており、クライアントが接続するのを待ちます。クライアントの確認を受信すると、その情報を保存します。すべてのクライアントが接続されると、隣接するクライアントの情報をすべてのクライアントに送信して、ネットワークを形成できるようにします。それはここにあります、私は多くのソケットを監視するためにselect()を使用します、マスターはそれに接続されているすべての子へのソケットを持っていますクライアントは3つのメインソケットを持っていますその隣人が接続を待機するソケット (つまり、隣人の S2) p- その隣人からの接続の結果であるソケット (s2 の受け入れ - ths を返します)接続して一度。

最初に、サーバーは文字列「hello」をクライアントの1つに送信し、クライアントはこのメッセージを受信して​​隣人に渡します。このようにして、文字列がサーバーからこのメッセージを受信した最初の子に戻ると、それを渡しますその隣に。しかし、すべての子は select() で入力を待っています。何が原因でしょうか??

前もって感謝します。

0 投票する
1 に答える
636 参照

c++ - Telnet を使用して select() をテストする

私は Linux/socket プログラミングにかなり慣れていません。サーバープログラムで接続を確認するために使用selectしています(最終的にはチャットルームサーバーになります)。私はそれをテストするためにtelnetを使用していますが、何か奇妙なことが起こっています。最初に telnet (telnet localhost 5794) を実行するselectと、1 が返され、マスター ファイル記述子リストに新しい接続が追加されます。すべてがうまく見えます。

しかし、telnet で入力しようとしても何も起こりません。新しい telnet セッションを開かない限り、Select は 0 を返します。

select新しいつながりを見つけるためだけですか?入力のチェックにも使えると思いました。以下は私のコードのコピーです (ここ数時間猛烈にいじっていたので、現時点では少し面倒です。申し訳ありません)。

編集: newConnection のコードは次のとおりです。

checkConnections 関数の先頭に printf があるため、関数に入るたびに確認できます。決して印刷されません。

0 投票する
2 に答える
1927 参照

c - FD_SET での C プログラミング エラー

コードに問題があり、select(); を初めて使用するため、何が問題なのかわかりません。
何が問題なのか誰か教えてください。




0 投票する
2 に答える
2991 参照

c - 非ブロッキングソケット選択は、接続後に1を返します

まず第一に、これはこれとは別の問題であると言いたい:似ているが同じではない

私のコードは次のようになります:

存在するマシンに接続しています(IPアドレスは存在しますが、接続しようとしているポートでリッスンしているサーバーがありません)。

Selectは常に1を返します。なぜですか?人によると、タイムアウトして0を返す必要があります。この後、ソケットに何かを書き込もうとすると、-1/ECONNREFUSEDが返されます。

これは予想される動作ですか?はいの場合、select()が接続されているかどうかを確認するにはどうすればよいですか?

0 投票する
1 に答える
486 参照

c - C exec/pipe/select プログラム - 子からの入力がありません

子スクリプトを生成するプログラムがあります。子スクリプトは、STDOUT および STDERR に 1/2 の時間で入力を単純に再発行します。残りの半分の時間は、静かに消費します。私が得ているのは、子への書き込みからの結果のタイミングのずれです。

行番号 1 は、同じ Line1 読み取りによって読み取られているはずです。同様に、回線番号 3 も同じ回線 3 の試行で検出されているはずです。

私が解決しようとしている問題は、データ行を子に書き込み、応答を確認して繰り返すことができるようにしたいということです。テストプログラムは次のとおりです。

子スクリプト:

親 C プログラム:

0 投票する
0 に答える
225 参照

c - select / sock ストリームの異常な動作

ファイルのチャンクを要求する小さなプログラムを作成してから、別のプログラムにそのファイルの特定のチャンクを返させます。約 555000 バイトまでのファイルを使用してこれを機能させることができますが、それよりも大きいファイルでは異常な動作が発生します。

私のループでは、整数の配列である進行状況バッファーをチェックして、ファイルの特定のチャンクがあるかどうかを確認します。送信する場合は、そのチャンクのリクエストを送信しませんが、送信しない場合は、ピアからチャンクをリクエストします。移動するリンクリストがあり、リスト内の各ピアにはそれに関連付けられた sockfd があります。つまり、ある意味で、私はリクエストを「ラウンド ロビン」します。送信したら、メッセージが届くのを待ちます。これが最善のアプローチかどうかはわかりませんが、最も自然な方法のように思えました。

ただし、より大きなファイルの場合、select 呼び出しでハングします。理由はよくわかりません。誰かがこれに光を当てたり、より良いアプローチを提案したりできるなら、私はそれを聞きたい.

これが私のコードです。呼び出す関数のコードは含めませんでしたが、この場合は必要ないと思います (これらは、Beej の sendall および recvall 関数の修正版です)。これはマルチスレッド アプリケーション (pthreads を使用) にあることにも言及する価値がありますが、共有変数は使用していません。これを読んでくれてありがとう!