I'm just making this post so people know that it isn't down since everyone will go psycho and kill a thousand starving Africans if they think RSBot died.

Asynchronous I/O is probably a good idea
So while it's odd that I am learning the difference between synchronous and asynchronous (non-blocking) I/O it's good that I am learning about it. I guess my inexperience when it comes to client-server programming coupled with the bad private server sources out there gave me the idea that everything must waste time.

That is not true with this, and I'll explain why. Synchronous blocks and asynchronous does not. Because of blocking you would need to update everyone at the same exact time on a different thread to avoid stopping the servers function.

Let's say you initiate a connection, you are then like "hi stream!!! read a byte!" It then stops on that code where you said "read a byte!" and waits for there to be a byte available to read and then resumes. This is blocking.

Let's say you initiate a connection, you are then like "hi stream!!! tell me when you have a byte to read!" It then lets you resume your normal tasks until it has a byte to read. Once it has that byte to be read it will interrupt your current process like Kanye West and call some cool method in your code that will read that precious byte from the stream.

It makes sense for it to only tell me that there's data to be read instead of going through all the sockets and being like "yo doq you got some data yo hook me up son."

Sure my examples and explanation may be a bit amateur but that only makes it apparent that I haven't done my tests yet! I'll know for sure what the fuck I'm talking about once I do some tests to help me wrap my head around (not literally, although that would be cool) this all.

www.youtube.com/watch?v=9jbEu9Ngh-U

That is Winterlove in C# lol. I fixed some issues and removed some unused references.

The reason in my previously released (on Fagex) version that it appeared to lag a little is because apparently Stream.ReadByte() blocks and to get around that I just commented it all out. It did nothing. You could keep the code in there by just breaking if there was no data available but whatever, it didn't come to mind when I was fixing it. I tried to fix the "lag" issue earlier by decreasing the processing sleep time to 50ms but when I removed the blocking code and it just skipped around really fast (50ms sleep isn't very long, duh). I just increased it to 500ms, the standard wait time. Yes I know that it should be 600ms but it works fine so whatever.

If you want to download the shitty source to this test go right ahead.

www.youtube.com/watch?v=FavUpD_IjVY