Server Query - Open Connection Issue

[Imisnew2]

Note:
For this message, please understand that the characters '\n', '\r' and '\0' refer to the ascii values 10, 13, and 0, respectively. Therefore, '\n' is equal to the "new line" character, '\r' is equal to the "line feed" character, and '\0' is equal to the "null" character.

Hello,
I posted a while ago (Server 3.0.1) with some issues related to \n\r and \0 not being present on the end of responses from the Teamspeak 3 server query interface. As I'm moving back into development on the project, I've found that the welcome message from the Teamspeak 3 server does not append a \0 to the end. For example:

TS3\n\r\0Welcome to the TeamSpeak 3 ServerQuery interface, type "help" for a list of commands and "help <command>" for information on a specific command.\n\r

Note:
The bolded \0 in the above response is normally removed by the socket. I've included it in this example to better explain the second issue described at the end of this post.

This causes the socket I'm using to receive information to time out while waiting for more information. I'm able to work around this by waiting an arbitrary amount of time before reading from the socket, then checking to see if it ends with \n\r, but this is sub-optimal. If I am doing something wrong, please let me know.

Also, the "TS3\n\r" portion ends with a \0 regardless if there is a Teamspeak 3 welcome message or not. Without manually waiting before receiving the response, it's impossible to tell if more information is being transmitted or not. Even then, you may not wait long enough and miss the response anyway.

Edit:
This was tested on server version 3.0.3.

[Imisnew2]

Ok, any takers?

[Imisnew2]

Ok, any takers?

This would also technically be a bug, although I'd like to be proven wrong. Not sure when it got moved...

[R. Ludwig]

just validated this and you are right, there is a \0 added to the FIRST string we send to the socket. which is not a wanted behaviour from us.

i suggest to just remove any \0 and rely on \0x0a\0x0d

we change the tcp stack soon anyway, so we wont put any effort into this for now.