Re: C# Network and streams - C# Discussion Boards

9-May-17 11:12

Hello guys, i really need help for this
i'm writing in C# a client-server (not important maybe, but it's for a game), probably i need more knowledge and clarification about the process.

Firts of all, the process is the same for client and server, and EVERYTHING IS (+or-)WORKING.

My code should explain what i'm doing

/// STREAM READER
new Thread(() =>
{
	int i = 0;
	while (true)
	{
		byte[] bytes = new byte[102400]; // 100k max buffer
		NetworkStream stream = client.GetStream();

		int received = stream.Read(bytes, 0, bytes.Length);
		Console.WriteLine("Packets: " + ++i);

		// Binary deserialization
		var basepacket = TNetwork.Encaps.Deserialize(bytes, 0, received);
		Thread.Sleep(1000);

	}
}).Start();

But there are some points that i don't get.

1) If i Send packets quickly

while(spamtest)
	bp.Send(stream, ...);

the other point doesn't process all incoming data if it is busy (send 1000, processed 200). How to solve? i won't lose informations. there are no a kinda of SampleAndHold system? How is possible that i'm losing tcp packets just cause the program was busy??

2) I tried to send some data of 2k over the network (with another pc) but i had no problems. MTU is 1500 so my endpoint should crash getting incomplete binary-serialized-classes ! No?

I'm going crazy. My implementation is ok or i'm missing something?

3) Maybe client.GetStream(); can i only write or read at once? If i write, can't read? neither with 2 threads?

4) Probably i have to separate the Send process to a Queue in another thread.

5) What does exactly the flush()? I need to use it? I tried with and without Flush() after stream.write no differences (autoflush is false).

6) if i let client spam 70.000 packets, at the end one of both crashes

Help me please, getting crazy. Thanks

modified 10-May-17 8:17am.

Bernhard Hiller9-May-17 21:30

Bernhard Hiller

9-May-17 21:30

Your code shows some misunderstandings: the inner while loop will start many threads in very short intervals - likely long before any of the already started threads has finished its work. A short wait time in between may be appropriate.
Your comment

// Do works ... Consider that classes are shared between clients and servers
// so classes are Invoked ...

is unintellegible. What is the problem you want to solve with that? And why do you think your solution does so?
Also, I don't see any use of int i = 0.
The code may become better readable when you refactor the bodies of the threads into functions.
Also note that an exception in a thread may crash your program if you don't handle it inside that thread.

TheTrigger10-May-17 2:26

10-May-17 2:26

Hi, i have removed useless code.

Now you can see, with Thread.Sleep(1000) i lose a lot of packets (more time, more loss. ~1000sent, ~40received). The above sketch code is the receiver.

What can I do to avoid losing packets?

Yes i know about handle inside threads
Hope you can help me, Thanks

Dave Kreskowiak10-May-17 2:38

10-May-17 2:38

You put the thread that is receiving data to sleep for 1 second upon the receipt of data and you wonder why you're losing packets?

A guide to posting questions on CodeProject

Click this: Asking questions is a skill.
Seriously, do it.

Dave Kreskowiak

TheTrigger10-May-17 2:52

10-May-17 2:52

Yes, i lose packets anyway.. Without .Sleep i get 1000sent/800received.
Client and server are in the same pc actually

Dave Kreskowiak10-May-17 4:31

10-May-17 4:31

You should never have a Sleep anywhere in your network code.

Also, you're receive code seems to think that when a client sends a message, you get the entire message in one go without regard to a message potentially being split up into multiple Reads. You Read however many bytes are told you received and deserialize them, even if the message is incomplete. The next read will also fail to deserialize properly because now you don't have the first part of the message but you have the trailing end of it, not a complete message.

Your losing "messages", not packets. Those are two totally separate concepts and cannot be used interchangeably.

It would seems that your client and server code has no method of delineating messages from each other. Where in the stream of bytes read can your code determine that a new message has started? You should only try to deserialize the data when you are sure you have a complete message in the buffer. That's what you have to implement.

A guide to posting questions on CodeProject

Click this: Asking questions is a skill.
Seriously, do it.

Dave Kreskowiak

TheTrigger10-May-17 5:48

10-May-17 5:48

> You should never have a Sleep anywhere in your network code
Using Sleep only for the example to emulate a computational delay

You are right, i'm confusing packets and messages sorry and thank.

I missed to say that: if i send messages slowly, the receiver can handle all messages without any issues.
The problem is when i send more message than the receiver can handle. Maybe i'm mad, but i won't lose messages!

The strange thing is, if i send a 2KB message over the network, the message have to be splitted, right? Cause of MTU. i should receive 2 messages? I still receive one, no crashes. So i need clarity.

As i said in the main post, i get crash only if i send a lot of messages much quickly

modified 10-May-17 11:57am.

Dave Kreskowiak10-May-17 6:41

10-May-17 6:41

If a message exceed the data payload size of a packet on a pipe, it is broken into multiple packets. You cannot attempt to deserialize the data until all packets for the message have been received. You're current code doesn't do that.

Your server code has no method of telling a client that 1) data is coming and this is how many bytes to expect (header), the data itself, and a checksum to validate that the data is OK (if necessary). These things do not have to be separate messages.

The client should not attempt to deserialize the data unless it 1) saw the message header and knows how many bytes to expect, 2) captured the data in the buffer, and checksummed the data to make sure it was OK (if necessary).

If the client receives anything it doesn't recognize or too few/many bytes, it should not attempt to deserialize the data. It should (optionally) tell the server to resend the data and go back to waiting for a new header.

System.ItDidntWorkException: Something didn't work as expected.

A guide to posting questions on CodeProject

Click this: Asking questions is a skill.
Seriously, do it.

Dave Kreskowiak

TheTrigger10-May-17 9:12

10-May-17 9:12

So you suggest to send 4 bytes that's the length of the message and a some bytes for the checksum, which protocol you suggest for the cksum? md5? there are something lighter?

I will do that (after fix message loss)

Any ideas to avoid loss of messages? Sigh | :sigh:

thanks for your time guys

Dave Kreskowiak10-May-17 11:52

10-May-17 11:52

Normally, I would start with a message delineation marker, say 3 bytes of 'F0', then a 32-bit message length, then then message. The checksum is options, but if it's used, that would be supplied after the message length and before the message. Typically, the message is going to be a variable length so it should show up last.

|Start of Message|Length in bytes|CheckSum|Message bytes...|
|    F0 F0 F0    |  00 00 00 1A  |   F6   |data bytes...   |

You don't get it. This may just fix your message loss because as your code stands right now, since you don't have any way of knowing when a message begins and ends, you have no way of knowing if the data you deserialize is valid! You could be deserializing the end bytes from the last message combined with the beginning bytes of the next message thinking it's valid when it's not.

System.ItDidntWorkException: Something didn't work as expected.

A guide to posting questions on CodeProject

Click this: Asking questions is a skill.
Seriously, do it.

Dave Kreskowiak

TheTrigger10-May-17 22:48

10-May-17 22:48

Problem solved .. you were right when you said "you're receive code seems to think that when a client sends a message, you get the entire message in one"

Now everything works perfectly

public static void CopyStream(Stream input, Stream output, int MaxLength)
{
	int read, totalread = 0;
	byte[] buffer = new byte[81920];
	while (totalread < MaxLength)
	{
		read = input.Read(buffer, 0,
			(
				((MaxLength - totalread) < buffer.Length) ?
					(MaxLength - totalread) :
					buffer.Length
			)
		);

		if (read == 0) break;

		totalread += read;
		output.Write(buffer, 0, read);
	}
}

modified 12-May-17 10:05am.

Gerry Schmitz10-May-17 5:00

Gerry Schmitz

10-May-17 5:00

The usual "pattern" is that the client "asks" for data that the server then sends.

You seem to be arbitrarily shoving data at clients and then expecting them to somehow keep up.

Ever been force fed without choking?

"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal

TheTrigger10-May-17 5:56

10-May-17 5:56

I need to send data arbitrarily over the time or period (like 20times per second), not ask-resp. I could switch to UDP, don't know yet.

> Ever been force fed without choking?
Maybe handle X requests, then drop the extras

Dave Kreskowiak10-May-17 6:25

10-May-17 6:25

You've got a bigger problem with UDP. Your client must be tolerant of lost or corrupted data. UDP does not guarantee delivery of any packet nor does it even guarantee the order in which they arrive!

System.ItDidntWorkException: Something didn't work as expected.

A guide to posting questions on CodeProject

Click this: Asking questions is a skill.
Seriously, do it.

Dave Kreskowiak

TheTrigger10-May-17 8:50