This is just a little newsflash, and a note to myself.
Following new command ideas/requests will be implemented soon:
commands for sending/recieving other data types with TCP streams: byte, word, dword, int, float
A channel group mechanism that will let you create groups for channels; add channels to that group, send message to the entire group, refresh the group to check for incoming data, disconnect the group, delete the group, and an optional flag to delete also the channels.
As I started to work on the first idea, I realized I need to extend the recieving mechanism of TCP altogether. Hence a new idea arose:
Make an indicator of data overflow; new command that returns 1 if your program is too slow to recieve the incoming data (this does not yet mean that data is lost).
I also realised that there is a danger of a READ buffer overflow, which has to be dealt with:
[errata]
the following was not correct:
Quote: "
Recieving strings with the normal "winsock recv string" command can cause the dll to read over the end of the data buffer, if the string is not 0 terminated. I will change this to use a length indicator at the beginning of the string."
instead, the whole buffer was treated as a string and then null-terminated. Since we now want to distinguish data from being string and variables of other data types, I need to indicate where the string stops. I did this now with a two byte length indicator at the beginning of the string.
[/errata]
These are the news, for those who care.
Thanks for your attention