本当に「プッシュ」というものはありますか？

電気信号の領域から脱出し、ソフトウェアを処理しているときに、定期的なポーリングが行われない「プッシュ」アーキテクチャのようなものは本当にありますか？

あるレベルでポーリングしていないデザインは考えられません。それは常に、あなたが扱っている実際の抽象化/ APIの1レベルか2レベル下にあるようです。ほとんどの「プッシュ」接続の受信側のソケットは、着信要求などをポーリングするだけです。

Windowsでは、NTとWindows 95までIOをポーリングするアプリケーションが必要だったと思います。現代の汎用オペレーティングシステムでは、ポーリングの必要性がほとんどなくなりました。アプリケーションがソケットからの読み取りを要求するとき、読み取り関数はオペレーティングシステムカーネルを呼び出す必要があります。OSは、呼び出しスレッドを中断状態にします。ネットワークパケットが着信すると、OSによって処理されるハードウェア割り込みがトリガーされます。パケットがアプリケーションが探しているパケットである場合、OSはスレッドを中断状態から解除し、読み取りを続行できます。つまり、アプリケーションは実際にはOSを介して電気信号の領域に結合されています。

websocketアーキテクチャはプッシュアーキテクチャであり、実際には交換と展望もそうです。これらのプロトコルは常にサーバーに接続されたままであり、サーバーはメッセージがあるときはいつでもメッセージを送信（プッシュ）します...

Charlesがすでに提示したソケットは確かに「プッシュ」デザインであると考えます。彼は電気信号の領域からずっと上まで歩きましたが、考慮すべきもう1つのトピックは、純粋にアプリケーションアーキテクチャの決定であり、はるかに高い抽象化レイヤーで発生する「プッシュ」設計です。

一般的なイベントフレームワークはプッシュと見なされます。イベントソースは、誰がリッスンしているかに関係なく、またはイベントシンクがそれらのイベントに追いつくことができるかどうかに関係なくイベントを発生させるからです。

もう1つの例は、私が作業している領域で、ビデオストリーミングです。RTP（リアルタイム転送プロトコル）を使用します。これはUDP / IPベースであり、本来はプッシュプロトコルです。送信者は、受信者がそれに追いついていれば、気にせずに選択した速度でビデオを送信し続けます。

確かにあります。たとえば、UnixのUDPソケットアプリケーションは、pushとして使用できます。最もよく知られているのは、syslogd着信（「プッシュ」）パケットを受け入れ、それらを処理する意思を宣言する古典的なBSD Unix です。アプリケーションまたはプロトコルレベルでのリバース通信はありません（「プッシャー」は、パケットが正しく受信および処理されたかどうかさえ知りません）。受信アプリケーション内のAPIレベルでは、ポーリング、同期、またはコールバックの受信メカニズムがあり、後者の2つは純粋なプッシュです。