Develop Reference

NetworkStream write() with event name

I have a simple TCP server written in C#, pinging out data at a specified interval and receiving the data I have a NodeJS app.
I'm current sending the data from a NetworkStream like so:
private NetworkStream nwStream;
nwStream = clientMachine.GetStream();
nwStream.Write(buffer, 0, buffer.Length); // Inside a loop
And receiving it in NodeJS like:
client.on('data', (data) => {
Is there any way to emit a different event, other than data from my C# TCP server? Using Socket.io I can socket.emit('customEvent', someData) and receive it like socket.on('customEvent', receivedData) but I'm unsure if I can achieve this in C#.
I'm not working with Socket.io, the above is just an example of the behaviour I'd like to achieve.

If you're using raw sockets at both ends, you'll just have to design your own protocol that embeds a name into each logical frame... TCP sockets themselves don't have any such mechanism, nor do raw packets.
A typical / simple way of doing this might be something like:
{Event name, UTF8}\r\n{length, 4 bytes little endian integer}{payload, length bytes}
If your event name might include newline/linefeed, then you'd need to use the payload length/payload approach for the event name, too.

Socket.IO has it's own network protocol specified here. The encodeAsString(obj) function in 'socket.io-parser' may be what you're looking for.

C++ socket reading side reads all messages concatenated

Hi I have a socket programming with C# Socket Server and C++ Socket Client.
Server I use Socket.Send(bytes[]) to send message
CPP Client side i use recv(socket,buffer,length,flags)
But in server if i send multiple messages concurrently on the client side i recieve all messages as concatenated.
for(int i=0;i<10;i++)
{
var bytes= GetBytes("msg"+i);
theSocket.Send(bytes);
}
C++ Socket CLient:
Thread.Start()
{
var msg = recv(theSocketClient,buffer,1024,0);
ProcessMessageFromSocket(msg);
}
Expected is:
process msg1 then
Process msg2... Process msg10
Actual:
processMessage(msg1msg2msg3...msg10 );
What i am missing?
my attempts to fix this:
1. C# NetworkStream.Flush() -- Even after this it gives me concatenated strings
2. CPP Everytime after finishing the read i erase the buffer (but the actual socket has data concatenated so this did not help)

It's normal for it to work this way. It's up to you to define your own protocol for splitting up data, for example you might to choose to start each transmission with 4 bytes telling you how long that transmission is.

Simples - TCP cannot transfer any messages longer than one byte - it's an octet/byte stream.
If you want to transfer messages longer than one byte, you need another protocol on top of TCP.

Loop until TcpClient response fully read [duplicate]

This question already has answers here:
Receiving data in TCP
(10 answers)
Closed 2 years ago.
I have written a simple TCP client and server. The problem lies with the client.
I'm having some trouble reading the entire response from the server. I must let the thread sleep to allow all the data be sent.
I've tried a few times to convert this code into a loop that runs until the server is finished sending data.
// Init & connect to client
TcpClient client = new TcpClient();
Console.WriteLine("Connecting.....");
client.Connect("192.168.1.160", 9988);
// Stream string to server
input += "\n";
Stream stm = client.GetStream();
ASCIIEncoding asen = new ASCIIEncoding();
byte[] ba = asen.GetBytes(input);
stm.Write(ba, 0, ba.Length);
// Read response from server.
byte[] buffer = new byte[1024];
System.Threading.Thread.Sleep(1000); // Huh, why do I need to wait?
int bytesRead = stm.Read(buffer, 0, buffer.Length);
response = Encoding.ASCII.GetString(buffer, 0, bytesRead);
Console.WriteLine("Response String: "+response);
client.Close();

The nature of streams that are built on top of sockets is that you have an open pipeline that transmits and receives data until the socket is closed.
However, because of the nature of client/server interactions, this pipeline isn't always guaranteed to have content on it to be read. The client and server have to agree to send content over the pipeline.
When you take the Stream abstraction in .NET and overlay it on the concept of sockets, the requirement for an agreement between the client and server still applies; you can call Stream.Read all you want, but if the socket that your Stream is connected to on the other side isn't sending content, the call will just wait until there is content.
This is why protocols exist. At their most basic level, they help define what a complete message that is sent between two parties is. Usually, the mechanism is something along the lines of:
A length-prefixed message where the number of bytes to be read is sent before the message
A pattern of characters used to mark the end of a message (this is less common depending on the content that is being sent, the more arbitrary any part of the message can be, the less likely this will be used)
That said you aren't adhering to the above; your call to Stream.Read is just saying "read 1024 bytes" when in reality, there might not be 1024 bytes to be read. If that's the case, the call to Stream.Read will block until that's been populated.
The reason the call to Thread.Sleep probably works is because by the time a second goes by, the Stream has 1024 bytes on it to read and it doesn't block.
Additionally, if you truly want to read 1024 bytes, you can't assume that the call to Stream.Read will populate 1024 bytes of data. The return value for the Stream.Read method tells you how many bytes were actually read. If you need more for your message, then you need to make additional calls to Stream.Read.
Jon Skeet wrote up the exact way to do this if you want a sample.

Try to repeat the
int bytesRead = stm.Read(buffer, 0, buffer.Length);
while bytesRead > 0. It is a common pattern for that as i remember.
Of course don't forget to pass appropriate params for buffer.

You dont know the size of data you will be reading so you have to set a mechanism to decide. One is timeout and another is using delimiters.
On your example you read whatever data from just one iteration(read) because you dont set the timeout for reading and using default value thats "0" milisecond. So you have to sleep just 1000 ms. You get same effect with using recieve time out to 1000 ms.
I think using lenght of data as prefix is not the real solution because when socket is closed by both sides, socket time-wait situation can not handled properly. Same data can be send to server and cause server to get exception . We used prefix-ending character sequence. After every read we check the data for start and end character sequence, if we cant get end characters, we call another read. But of course this works only if you have the control of server side and client side code.

In the TCP Client / Server I just wrote I generate the packet I want to send to a memory stream, then take the length of that stream and use it as a prefix when sending the data. That way the client knows how many bytes of data it's going to need to read for a full packet.

How can my program know when the server is done processing my request?

I am connecting to my mail server using IMAP and Telnet. Once I am connected I am marking all items in the inbox as read. Some times the inbox will only have a couple of e-mails, sometimes the inbox may have thousands of e-mails. I am storing the response from the server into a Byte array, but the Byte array has a fixed length.
Private client As New TcpClient("owa.company.com", 143)
Private data As [Byte]()
Private stream As NetworkStream = client.GetStream()
.
. some code here generates a response that I want to read
.
data = New [Byte](1024) {}
bytes = stream.Read(data, 0, data.Length)
But the response from the server varies based on how many e-mails are successfully marked as read since I get one line of confirmation for each e-mail processed. There are times where the response may contain only 10-20 lines, other times it will contain thousands of lines. Is there any way for me to be able to get the response from the server in its entirety? I mean it seems like I would have to know when the server was done processing my request, but I'm not sure how to go about accomplishing this.
So to reiterate my question is: How can I check in my program to see when the server is done processing a response?

I believe you can use the NetworkStream's DataAvailable property:
if( stream.CanRead)
{
do{
bytes = stream.Read(data, 0, data.Length);
//append the data read to wherever you want to hold it.
someCollectionHoldingTheFullResponse.Add( data);
} while( stream.DataAvailable);
}
At the end, "someCollectionHoldingTheFullResponse" (memory stream? string? List<byte>? up to your requirements) would hold the full response.

Why not just check the unread mail count? If there are no unread mail, then all have been marked as unread :)

This article has an interesting example of C# code communicating over TCP to a server. It shows how to use a While loop to wait until the server has sent over all data over the wire.
Concentrate on the HandleClientComm() routine, since this some code you may wish to use.

Handling dropped TCP packets in C#

I'm sending a large amount of data in one go between a client and server written C#. It works fine when I run the client and server on my local machine but when I put the server on a remote computer on the internet it seems to drop data.
I send 20000 strings using the socket.Send() method and receive them using a loop which does socket.Receive(). Each string is delimited by unique characters which I use to count the number received (this is the protocol if you like). The protocol is proven, in that even with fragmented messages each string is correctly counted. On my local machine I get all 20000, over the internet I get anything between 17000-20000. It seems to be worse the slower connection that the remote computer has. To add to the confusion, turning on Wireshark seems to reduce the number of dropped messages.
First of all, what is causing this? Is it a TCP/IP issue or something wrong with my code?
Secondly, how can I get round this? Receiving all of the 20000 strings is vital.
Socket receiving code:
private static readonly Encoding encoding = new ASCIIEncoding();
///...
while (socket.Connected)
{
byte[] recvBuffer = new byte[1024];
int bytesRead = 0;
try
{
bytesRead = socket.Receive(recvBuffer);
}
catch (SocketException e)
{
if (! socket.Connected)
{
return;
}
}
string input = encoding.GetString(recvBuffer, 0, bytesRead);
CountStringsIn(input);
}
Socket sending code:
private static readonly Encoding encoding = new ASCIIEncoding();
//...
socket.Send(encoding.GetBytes(string));

If you're dropping packets, you'll see a delay in transmission since it has to re-transmit the dropped packets. This could be very significant although there's a TCP option called selective acknowledgement which, if supported by both sides, it will trigger a resend of only those packets which were dropped and not every packet since the dropped one. There's no way to control that in your code. By default, you can always assume that every packet is delivered in order for TCP and if there's some reason that it can't deliver every packet in order, the connection will drop, either by a timeout or by one end of the connetion sending a RST packet.
What you're seeing is most likely the result of Nagle's algorithm. What it does is instead of sending each bit of data as you post it, it sends one byte and then waits for an ack from the other side. While it's waiting, it aggregates all the other data that you want to send and combines it into one big packet and then sends it. Since the max size for TCP is 65k, it can combine quite a bit of data into one packet, although it's extremely unlikely that this will occur, particularly since winsock's default buffer size is about 10k or so (I forget the exact amount). Additionally, if the max window size of the receiver is less than 65k, it will only send as much as the last advertised window size of the receiver. The window size also affects Nagle's algorithm as well in terms of how much data it can aggregate prior to sending because it can't send more than the window size.
The reason you see this is because on the internet, unlike your network, that first ack takes more time to return so Naggle's algorithm aggregates more of your data into a single packet. Locally, the return is effectively instantaneous so it's able to send your data as quickly as you can post it to the socket. You can disable Naggle's algorithm on the client side by using SetSockOpt (winsock) or Socket.SetSocketOption (.Net) but I highly recommend that you DO NOT disable Naggling on the socket unless you are 100% sure you know what you're doing. It's there for a very good reason.

Well there's one thing wrong with your code to start with, if you're counting the number of calls to Receive which complete: you appear to be assuming that you'll see as many Receive calls finish as you made Send calls.
TCP is a stream-based protocol - you shouldn't be worrying about individual packets or reads; you should be concerned with reading the data, expecting that sometimes you won't get a whole message in one packet and sometimes you may get more than one message in a single read. (One read may not correspond to one packet, too.)
You should either prefix each method with its length before sending, or have a delimited between messages.

It's definitely not TCP's fault. TCP guarantees in-order, exactly-once delivery.
Which strings are "missing"? I'd wager it's the last ones; try flushing from the sending end.
Moreover, your "protocol" here (I'm taking about the application-layer protocol you're inventing) is lacking: you should consider sending the # of objects and/or their length so the receiver knows when he's actually done receiving them.

How long are each of the strings? If they aren't exactly 1024 bytes, they'll be merged by the remote TCP/IP stack into one big stream, which you read big blocks of in your Receive call.
For example, using three Send calls to send "A", "B", and "C" will most likely come to your remote client as "ABC" (as either the remote stack or your own stack will buffer the bytes until they are read). If you need each string to come without it being merged with other strings, look into adding in a "protocol" with an identifier to show the start and end of each string, or alternatively configure the socket to avoid buffering and combining packets.