#Naming

You code's naming conventions are very inconsistent (which possibly reflects the fact that you've taken bits of it from different sources). Generally speaking, I expect local variables to follow a camelCasing naming convention. Your current approach ends up with lines like this:

catch (Exception StreamException)

Which honestly at first glance made me ask the question 'have they done something funky with exception filters'.

#Exceptions

You don't actually do anything with any of the exceptions that you catch. If you don't need to access the variable, then you can simply catch the exception:

catch (Exception)

Typically you'd also want to try to avoid catching base exception. It suggests that you don't really know what exceptions can be thrown. Sometimes it's the right thing to do, but more often than not you should be catching more specific exceptions so that you can take more appropriate action.

#When you're done, you're done

Your thread function in your server contains an endless loop. This works whilst the client is behaving, but falls apart once you encounter an error. Within the loop, you're catching all exceptions and responding by closing the socket:

catch (Exception StreamException)
{
 Console.WriteLine("Connection from a client closed.");
 ClientSocket.Close();
}

Best case, the second time you call Close, it throws an exception and the thread function crashes. Worst case, the Close doesn't throw an exception and you don't notice that the thread function is in an endless loop, eating processor time.

Once you've closed the connection, you should return from the thread function to prevent the pointless spinning.

Naming

You code's naming conventions are very inconsistent (which possibly reflects the fact that you've taken bits of it from different sources). Generally speaking, I expect local variables to follow a camelCasing naming convention. Your current approach ends up with lines like this:

catch (Exception StreamException)

Which honestly at first glance made me ask the question 'have they done something funky with exception filters'.

Exceptions

You don't actually do anything with any of the exceptions that you catch. If you don't need to access the variable, then you can simply catch the exception:

catch (Exception)

Typically you'd also want to try to avoid catching base exception. It suggests that you don't really know what exceptions can be thrown. Sometimes it's the right thing to do, but more often than not you should be catching more specific exceptions so that you can take more appropriate action.

When you're done, you're done

Your thread function in your server contains an endless loop. This works whilst the client is behaving, but falls apart once you encounter an error. Within the loop, you're catching all exceptions and responding by closing the socket:

catch (Exception StreamException)
{
 Console.WriteLine("Connection from a client closed.");
 ClientSocket.Close();
}

Best case, the second time you call Close, it throws an exception and the thread function crashes. Worst case, the Close doesn't throw an exception and you don't notice that the thread function is in an endless loop, eating processor time.

Once you've closed the connection, you should return from the thread function to prevent the pointless spinning.