Quote Originally Posted by TeraBaap View Post
i wish i could do but i believe i have to rewrite over 150+ lines of code if i start over most of my the work is done other than this and i'd like to continue with the best possible solution in my current case D:
This is the wrong thinking. I recently had to rewrite a portion of my own Winsock application because I clumsily kept tacking on features to its file transfer protocol which resulted in a huge mess that was difficult to debug. It took me nearly two weeks and a little pain to rewrite it from scratch but it had to be done to spare me even more headaches in the future. Mine was way more than 150 lines of code. It was closer to 2000 lines of code. My rewrite resulted in less code that's better organized something like 800 lines. When something has to be done, it just has to be done.

That being said, the way you designed your protocol is not very good. Firstly, you're searching for a length prefix inside a data stream. Assuming you're using the TCP protocol which is reliable, you shouldn't be doing this. Every stream of data you send should start with a known header and from there you can use a length field to determine how much data your payload has and you use the length of the header to know where the payload starts. From there you can determine where the next piece of data should be in the stream which should also start with a header. Every time you have a full message in the stream, you can remove it from the stream so the stream again begins with a header. You should never have to scan a stream for data. That would make your protocol terrible slow and not to mention, unreliable.

Also, like dilettante said, you really shouldn't be playing around with binary data inside a string. If you like, I can show you the correct way to convert a series of bytes into a Long and vice versa.