2009-11-06 7 views
27

Se invio due messaggi TCP, devo gestire il caso in cui quest'ultimo arriva prima del primo? O è garantito arrivare nell'ordine in cui lo mando? Presumo che questo non sia un esempio specifico di Twisted, perché dovrebbe essere conforme allo standard TCP, ma se qualcuno che ha familiarità con Twisted potrebbe fornire una risposta Twisted per la mia tranquillità, sarebbe apprezzato :-)Il TCP è garantito per arrivare in ordine?

+3

Dato che TCP non ha idea di dove i tuoi messaggi iniziano o alla fine, come potrebbe forse riordinarle, anche se lo volesse? –

risposta

44

Fintanto che i due messaggi sono stati inviati sulla stessa connessione TCP, l'ordine verrà mantenuto. Se vengono aperte più connessioni tra la stessa coppia di processi, potrebbe essere nei guai.

Per quanto riguarda Twisted, o qualsiasi altro sistema di eventi asincroni: mi aspetto che riceverai i messaggi dataReceived nell'ordine in cui vengono ricevuti i byte. Tuttavia, se inizi a spingere il lavoro su chiamate differite, puoi, erm ... "distorcere" il tuo flusso di controllo oltre il riconoscimento.

7

TCP è uno stream, UDP è un messaggio. Stai mescolando i termini. Per TCP è vero che lo stream arriverà nello stesso ordine in cui è stato inviato. Non ci sono messaggi distict in TCP, i byte appaiono quando arrivano, interpretandoli come i messaggi dipendono da te.

+1

Re: termini - Sì, certo. Tuttavia, Twisted riassume ciò in messaggi distinti (quindi interpretarli come messaggi non dipende da me) – Smashery

+0

E vale la pena notare che mentre si potrebbero avere due scritture sul lato del mittente, potrebbero collassare in una singola lettura sul lato ricevente, e vice versa: dipende dalle dimensioni del buffer e dalle condizioni della rete. –

+1

No, Twisted non estrae il TCP in "messaggi". Otterrete un blocco di byte (fino a un byte alla volta in casi estremi) nel protocollo di base. – truppo

20

TCP è orientato alla connessione e offre ai propri clienti la consegna in ordine. Ovviamente ciò vale per il livello di connessione: le singole connessioni sono indipendenti.

Si noti che normalmente si fa riferimento a "flussi TCP" e "messaggi UDP".

Qualsiasi sia la libreria Client che si utilizza (ad esempio Twisted), la connessione TCP sottostante è indipendente da essa. TCP consegnerà i "messaggi di protocollo" al tuo cliente. Con "messaggio di protocollo" mi riferisco ovviamente al protocollo che usi sul livello TCP.

Ulteriore nota che I/O operazione sono asincrona in natura e molto dipende dal carico di sistema anche + capitalizzazione di rete ritarda & perdite, non si può fare affidamento su un messaggio di ordinare tra connessioni TCP.

+0

Che cosa intendi per _travi collegamenti TCP? – simplename

11

TCP "garantisce" che un destinatario riceverà il flusso di byte ricostituito come originariamente inviato dal mittente. Tuttavia, tra gli endpoint di invio/ricezione TCP (vale a dire la rete fisica), i dati possono essere ricevuti senza ordine, possono essere frammentati, possono essere danneggiati e possono persino essere persi. TCP considera questi problemi utilizzando un meccanismo di handshake che provoca la ritrasmissione di pacchetti difettosi. Lo stack TCP sul ricevitore colloca questi pacchetti nell'ordine in cui sono stati trasmessi in modo che quando si legge dal socket TCP, si ricevano i dati come originariamente inviati.

Quando si chiama il metodo doRead in Twisted, i dati vengono letti dal socket fino alla dimensione del buffer. Questi dati possono rappresentare un singolo messaggio, un messaggio parziale o più messaggi. Spetta a te estrarre i messaggi dal buffer, ma a questo punto hai la garanzia che i byte siano nel loro ordine trasmesso.

Ci scusiamo per confondere le acque con il mio precedente post ...

+0

per favore rivisita la tua risposta in quanto ti sbagli molto. L'API esposta da TCP è molto un flusso con consegna ordinata in byte. Si fa riferimento qui al metodo di trasporto sottostante (cioè i pacchetti) che, ovviamente, non è garantito per arrivare in ordine. – jldupont

+0

FYI, il "livello server" per TCP è IP che è ovviamente "senza connessione" e non garantisce la consegna dell'ordine dei pacchetti. – jldupont

+0

Sei corretto. Chiarirò Grazie. –