foreskel på push og no push i tcp header

Jeg forstår ikke helt spørgsmålet. mener du hvad forskellen på om push flaget er sat eller ej. Jeg har aldrig hørt om no push

Jeg sender en række pakker via en socket, det jeg ser er at den sidste pakke har push flaget sat i tcp headeren. men det har de foregående ikke.

Jeg er ikke haj til tcp, så jeg vil gerne vide hvad forskellen er på en pakke hvor at push flaget er sat, og alle de foregående pakker hvor det IKKE er sat

eller kan du måske generelt forklare hvad push egentlig betyder?

Kan fortolkes som "end of transmission" og tvinger modtager TCP stak til at tømme sin buffer. Må ikke forveksles med "disconnect".

push flag (1 bits)
The push flag tells the receiving end of the tcp connection to "push" all buffered data to the receiving application. It basically says "done for now".

renehinsch>lige netop

Ok er vi så enige om at hvis en forkert pakke er push markeret, så kan det give lidt problemer ??

Teoretisk ja. Men det kræver at de data der frigives som så ikke kan samles korrekt af de øvre protokolstakke (applikationen). Normalt vil jeg ikke tro at det giver problemer. Måske hvis en applikation andvende en større MTU (max data størrelse) end dine underliggende TCP/IP/MAC lag kan håndtere og der derved teoretisk kan frigives data der er fragmenteret af TCP stakken (ikke af applikationen) før den sidste stump er modtaget. Men det kræver lidt mere granskning af RFC'en for at se om modtager blot ignorerer  push flag hvis fragment flaget er sat. Hvis den tillader det vil det alt efter hvor robust applikationen er bygget kunne få den til at afvise pakken og bede sender om en retransmission. Hvis applikationen er connection orienteret vil det ofte være ikke en fatal fejl.

ok det lyder tilforladeligt.

Har lige et bi spørgsmål, hvis jeg lider af problemer med acknowldge to long, det er altid på ack på den sidste pakke (den som er push) markeret. hvad kan det skyldes? ja jeg ved godt det er svært, når man ikke er sat helt ind i det, men måske du har et par ideer?.

Det kommer sørme an på hvem der mener ack er for langsom. Er det afsender TCP der siger det eller er det et ekspert modul in en protokolanalysator. Og hvor mange milisekunder drejer det sig om? Hvis afsender mener at ack er for langsom er det fordi den er timet ud og det vil så foranledige en retransmission - og det er jo ikke det du observerer. Protokolanalysatoren er baseret på en værdi som ofte kan justeres og den behøver ikke at være rigtig sat. Normalt vil man kunne sige at ack er for langsom hvis det påvirker data flow. Hvis det er fordi du ser varians mellem ack tid på pakker med og uden push flag kan netop push operationen bruge nogle ekstra milisekunder før den kan signalere tilbage til afsender at modtager nu har en tom buffer.

Jo det er et ekspert modul som peger det ud, men det har stor indflydelse på mit dataflow, jeg ser et delay på ca 190 ms. så jeg mener jo at min klient bruger for lang tid på at tømme bufferen.

Ja det er lang tid. Så må du kigge på din tcp stak og din applikation for at finde ud af hvad der sker når den laver en push og hvad der kan forårsage den lange pause. Det kan jo lige såvel være din applikation som bidrager til en langsom buffer push. Evt undersøge om du kan sætte tcp stakken til ikke at sende push. Men her stopper min viden og mulighed for at hjælpe dig videre desværre.

Du har været til stor hjælp, jeg takker

Selv tak! og held og lykke med at finde løsningen.