C'è davvero qualcosa come "spingere"?

Penso che Windows abbia richiesto alle applicazioni di eseguire il polling dell'IO fino a NT e Windows 95. I moderni sistemi operativi per scopi generici hanno praticamente eliminato la necessità di eseguire il polling. Quando l'applicazione richiede di leggere da un socket, la funzione di lettura deve effettuare una chiamata al kernel del sistema operativo. Il sistema operativo mette il thread chiamante in uno stato sospeso. Quando arrivano i pacchetti di rete, attivano un interrupt hardware gestito dal sistema operativo. Se il pacchetto è quello cercato dall'applicazione, il sistema operativo estrae il thread dallo stato sospeso e la lettura può procedere. In altre parole, la tua applicazione è in realtà accoppiata al regno dei segnali elettrici tramite il sistema operativo.

l'architettura websocket è un'architettura push, in realtà lo è anche lo scambio e l'amp; prospettiva. Questi protocolli restano connessi al server in ogni momento e il server invia messaggi (li spinge) ogni volta che ci sono messaggi ...

Prenderò in considerazione anche i socket che Charles ha già presentato al design "push". Ti ha guidato dal regno dei segnali elettrici, ma un altro argomento da considerare sono i progetti "push" che sono decisioni di architettura puramente applicative e si verificano a livelli di astrazione molto più elevati.

Tipici framework di eventi sarebbero considerati push, poiché la fonte di eventi attiverà eventi indipendentemente da chi li sta ascoltando, o se l'event sink è in grado di tenere il passo con quegli eventi.

Un altro esempio, che è l'area in cui lavoro, è lo streaming video. Lavoriamo con RTP (protocollo di trasporto in tempo reale). È basato su UDP / IP e per sua natura è un protocollo push. Il mittente continuerà a inviare video alla velocità che sceglie senza preoccuparsi del fatto che il ricevitore stia tenendo il passo con esso.

Certo che c'è. Le applicazioni socket UDP in Unix, ad esempio, possono essere pure-push. Il più noto sarebbe il classico BSD Unix syslogd , che dichiara la sua disponibilità ad accettare i pacchetti in entrata ("spinti") e li elabora. Nessuna comunicazione inversa a livello di applicazione o protocollo (il "pusher" non sa nemmeno se il pacchetto è stato ricevuto ed elaborato correttamente). A livello di API all'interno dell'applicazione ricevente, potrebbero esserci meccanismi di ricezione polling, sincrona o di richiamata, gli ultimi due dei quali sono pure-push.