Hi ArielUba,
thanks for wishes. I hope you had nice holidays.
I changed the protocol a little and it has a good reason.
One user confornted with following problem. He tried to communicate with server using wrong port-number. On that port run other daemon, so he did not got a message "Unable to send a request to server". The request was sent, but when the nzbget-client tried to analyse received response it failed with segmentation fault.
I tested it by trying to send messages to ftp server: "nzbget -P -o serverport=21".
This command printed: "nzbserver returned: 220 Welcome to FTP server"
The command, that analyse data, like list-command and log-command failed with segmentation fault.
In order to prevent such kind of problems and to give users better error-reporting I changed response messages. Now they all have additional first integer with NZBGET_SIGNATURE, like all request-messages have. For List- and Log-responses it is the only change, you need to account.
Simple responses (download, pause, unpause, set rate, edit-queue, quit), which early returned just a text message, now represented by following structure (sample for Download-response, but they all are same):
======
// A download response
struct SNZBDownloadResponse
{
SNZBResponseBasem_MessageBase;// Must be the first in the struct
int32_tm_bSuccess;// 0 - command failed, 1 - command executed successfully
int32_tm_iTrailingDataLength;// Length of Text-string (m_szText), following to this record
//charm_szText[m_iTrailingDataLength];// variable sized
};
======
Now via checking the signature, client can be sure it communicates with nzbget-server.
Please take into account these changes.
Best Regards,
hugbug