I have a problem when receiving large packets in Node.js through a TCP connection. It seems that there is a cap in the buffer set to about 55kB. When I receive large amounts of data (about 70-80k) it splits this data up.

Now, I've worked with UDP sockets, I know how to expect on('data', function(){}) events and how to expect an on('end', function(){}) when the message is finally received, the problem with the TCP is that I never receive an on('end', function(){}) event, the server (in C#) never sends a FIN packet. This is due to me requiring to keep the socket alive and ongoing (we don't want to shut it down).

Is there some sort of way to send a FIN packet, from the C# to the Node.js one, without having to shut down/close the socket?

Or, alternativelly, is some sort of way to trigger the on('end', function(){}) event inside node itself?

Regards.

EDIT: To add up to the question, say for instance I have 2 clients attempting to acquire information through the TCP socket. One connects first, and gets a huge request (no problem on the size here).

But whilst this request is being handled, another one does the same request, since the TCP connection is through node, they're using the same socket. Is there any way to differentiate the requests? or will I have to set up a socket for each request being done to the TCP server?

UDP is packet-oriented. You can send as much data as will fit in a packet, up to an absolute maximum of 65,507 bytes. It's fire and forget, with no intrinsic mechanism for handling packet loss or reordering.

TCP is stream-oriented. Your data will be split up into packets based on a few factors including volume of data and transmission rate. This is mostly beyond your control and managed by the TCP/IP stack. What you get in return is an ordered sequence of packets and a degree of fault-tolerance (correct packet ordering is guaranteed and lost/duplicate packets are detected and dealt with by the TCP/IP protocol stack transparently to application code).

If you're working at the socket level in node you will almost certainly get multiple callbacks, each containing a chunk of data. It's up to you to stitch it back together. This is a good thing - it means you can define your own mechanism for identifying message boundaries, data compression etc etc.