as i understand there are two ways about going with tcp sockets in c#
one is to use synchronous sockets and use your own threads to solve blocking the threads
and then there is async with callbacks…
i have devised a system where i am using a small pool of threads to manage a queue if input data from the main thread, then i call blocking socket code inside my own threads. i use locks to make the data available to the unity’s thread, thread safe.
i understand i could use async calls aswell, it uses the system thread pool, and probably uses less over head,
but i am only needing to get around blocking the main thread where i am requesting remote player locations and settings them, and thus it all does not need to be asynchronous,
and i am only using a small pool of threads, maybe 3 threads to a pool, to handle these two packets of data
is this bad practice, should i be using async in this situation, am i going to run into huge problems later?
i do this because i can then use binaryformatter directly with the networksteam and dont have to fuddle with memory streams or bytes arrays
any pointers? i have been having no luck getting any responses latley and i realize the information is there if i dig deep enough , but i have been getting mixed responses from the information i have googled.
I’ll try to explain why people generally do not use synchronous sockets.
The general advice is that if you are building a server software and spawn of one thread for each client socket, this will not scale. The context switching that happens between all the threads will end up costing you so much that your performance will suffer very very quickly. Depending on the CPU it might happen as soon as around 10-20 threads.
My advice is this: If you need to support more then 5 sockets, using one thread per socket will not work.
However, if you are building the “client” side of the application, this might work - as you generally only need 1-2 sockets open. The thing here is though that if you build the server side, you’re going to have to build it using some sort of asynchronous or polling method. So why not use the same socket code on the client also? It’s already written for the server.
pretty much decided to go back and re code the entire server using asynchronous methods, and delegates, moving worker threads to the thread pool, and thread safeing the database funcationality of the server.
then i will have to recode the networking manager for the client. atleast i wont have to restart the entire thing, just pop in a new network manager using asyncronous methods.
going to have to also add a few bytes before each packet so that the receiver can use a network stream and binary fomatter to serialize from so that it does not read to much or to little and give me errors. i was having this issue. need to make requests queue up in a thread safe manner i can read from threads inside unityAPI.
synchronous calls really made my code take a different flow than i realize that i am going to have to use. i thought i could get around some programming patterns by using the thread pool and synchronous calls… but somewhere something is screwing up and its better to do it right then to have patch work and it break at some point.