-
Notifications
You must be signed in to change notification settings - Fork 7.3k
Is there a way for one TCP packet one 'data' event? #node 0.10.35 #15443
Comments
No one meets this problem?
only first time call wirte(),it will send data immediately. |
There's two reasons why you're seeing this:
Check out nodejs/node#906 (comment) and following comments for some more discussion on the causes. |
thanks for your response @silvewind
it still doesn't work... |
I think what you're seeing is coalascing of socket writes. One 'data' event isn't always one packet. If you look at it in wireshark, you should see it sending each call in a single packet. If this is someting considered an issue or not, I can't answer. You should handle your data in a streaming way. |
@silverwind thanks,i understand what you said.But what i need is one packet one 'data' event |
I don't fully understand if this is caused by the kernel or by node. It may or may not be a node bug, will research. |
@dayuoba Thank you for reporting this issue! There's already an issue that describes Would you mind editing the title and description of this issue so that it better represent the remaining unknown issue, which is that for multiple TCP packets seem to result in only one |
@misterdjules ok, thanks for your response.but it did not resolve my issue,and right now i mush add a 'EOF' like symbol at the end of each message for what i want. |
TCP is a streaming protocol without message boundaries. There is no "packet" at the transport layer. |
@ravi i don't know the protocal details,but as i use setNoDelay(true),what i think is it should send data immediately,so i regard it as a |
@dayuoba that's a fair expectation: setting setNoDelay(true) should disable Nagle's algorithm at the TCP layer. I write to warn you that flushing TCP buffers in real-time provides no guarantee that they will be sent into and across the network in the same segment sizes you wrote them out in from the application, and more importantly, you can have no guarantee that they will be passed (by the network stack) to the receiver with the same packetization. In other words TCP_NODELAY does not imply message boundaries or guarantee message sizes. It just says to the kernel, don't buffer up bytes waiting for TCP acknowledgements, but send them down the wire (TCP window, etc, permitting) as you receive it. How these fragments get chopped up within the network and reassembled at the receiver is out of the scope of this setting (disclaimer: IP has some near-obsolete flags for fragmentation/reassembly control, but let's ignore those). If you perform one write operation of 300 bytes every 100 milliseconds, the only way Node, sitting atop TCP, can provide them back to the receiver in 300 byte chunks at a time is by imposing its own message boundaries on these messages, because TCP, by design, will not do that. But that is not Node core's task, to provide a sort of de facto application messaging protocol (each application protocol -- HTTP, SMTP, etc -- uses its own semantics). I am sure, however, that there are modules (not just methods like HTTP or WebSockets) that will provide you messaging semantics above TCP. I would suggest looking at one of these. Assuming I have understood your issue correctly :-), I hope that helps! |
@ravi great description. I think UDP might be the right tool for this job, if transmission errors can be handled in the application itself. |
Thank you @dayuoba, @silverwind and @ravi. Closing the coalescing of TCP packets as not an issue. The |
@ravi @silverwind 👍 much thx,learnd a lot |
As API doc mentioned.socket.nodelay defaults to
true
,but even i callsocket.setNoDelay(true)
,it didn't work well..reproduce code:
server.js
client.js
every time testing.the output is different.i don't know why.did i miss something?
output:
EDIT:I must say, i want one TCP packet one 'data' event was called.
The text was updated successfully, but these errors were encountered: