I would like to see your code, too but -- I can offer you some help anyway.
Always use try/catch for network communications and db access and ignore anyone that tells you not to -- unless it is your boss, but even then -- you should use it. I am saying this -- not to chastise you or puff myself up -- I am saying it because if you do you will not only learn how to fix this yourself -- you will learn to write code that can handle issues and also it will perform better. Generally, I will wrap most all of a function in try/catch if it involves communications or database access. You do not need it everywhere, just in key areas that warrant it.
If you ignore it altogether -- your application will halt because you did not use try/catch-- not good for anyone and not good for you. If you use try/catch -- at least you know that an error occurred and at least the code can exit gracefully instead of spitting out that page that tells your users that your code just died on them.
You said -- continuously -- but, the exception seems to be telling a different story. I suspect that your buffer read is either missing data that is in the buffer, or you are not servicing it often enough or -- your buffer is too small to begin with. TCP has some built-in defense against many errors, but it cannot force you to service the socket properly, so -- it is the buffer, the socket properties or your read code. How large is the expected data?
Mostly, guessing buffer sizes is a bad idea -- either you get one too small or you waste resources by making it too large. This is not a career where guessing is a good strategy and asynchronous communications demands that we code properly and not make assumptions.