Technical doc & Backward Compatibility

Get help, report and discuss bugs.
merlum

RE: Technical doc & Backward Compatibility

Post by merlum » 14 Dec 2007, 18:01

All is OK. My modifications are done quickly, to in the best way.
Please tell me if you want some help for test/documentation/other.
It is true for you too, hugbug.

Thierry

merlum

RE: Technical doc & Backward Compatibility

Post by merlum » 14 Dec 2007, 18:04

I wanted to write "not in the best way", my fingers crossed accidentally
Thierry

hugbug

RE: Technical doc & Backward Compatibility

Post by hugbug » 14 Dec 2007, 18:42

Hi all,

ArielUba, I'll release version 0.3.1 as soon as you are ready to release nzbgui. I can release new version any day, but I wait for possible change requests from you and may be bug reports/fixes/requests from all users.
Do not implement support for both versions, it is an unnecessary burden. Start with version 0.3.1.

Download-Request includes content of nzb-file. m_iTrailingDataLength is length of the content. m_szFilename is used for displaying and as a name for destination folder.

hugbug

RE: Technical doc & Backward Compatibility

Post by hugbug » 18 Dec 2007, 23:46

Hi,

I added a new field "uint32_t m_iParJobCount" to struct "SNZBListRequestAnswer". This field indicates how many par-jobs are currently queued in Par-Checker (including currently processed file, if any).

ArielUba, please update your code.
I also consider adding a new command to receive a list of files queued in Par-Checker, but I do not find any place for the list in built-in client. Let me know if you want this feature in your NZBGUI.

arieluba

RE: Technical doc & Backward Compatibility

Post by arieluba » 21 Dec 2007, 13:40

Hi hugbug,
I've updated the protocol. Currently I'm waiting for Underskin because he told me that he would implement some part.
About your question, I'm going to ask Underskin.

I hope you a merry Christmas

ArielUba

hugbug

RE: Technical doc & Backward Compatibility

Post by hugbug » 16 Jan 2008, 18:41

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

hugbug

RE: Technical doc & Backward Compatibility

Post by hugbug » 22 Jan 2008, 07:55

Hi ArielUba,

I added few new fields to List-Response: uptime, download-time, amount of total downloaded data and current state of server (are there any active downloads?). The SNZBListResponse-struct now looks as following:
===========
// A list response
struct SNZBListResponse
{
SNZBResponseBasem_MessageBase;// Must be the first in the struct
int32_tm_iEntrySize;// Size of the SNZBListResponseEntry-struct
int32_t m_iRemainingSizeLo;// Remaining size in bytes, Low 32-bits of 64-bit value
int32_t m_iRemainingSizeHi;// Remaining size in bytes, High 32-bits of 64-bit value
int32_tm_iDownloadRate;// Current download speed, in Bytes pro Second
int32_tm_iDownloadLimit;// Current download limit, in Bytes pro Second
int32_tm_bServerPaused;// 1 - server is currently in paused-state
int32_tm_iThreadCount;// Number of threads running
int32_tm_iParJobCount;// Number of ParJobs in Par-Checker queue (including current file)
int32_tm_iUpTimeSec;// Server up time in seconds
int32_tm_iDownloadTimeSec;// Server download time in seconds (up_time - standby_time)
int32_tm_iDownloadedBytesLo;// Amount of data downloaded since server start, Low 32-bits of 64-bit value
int32_tm_iDownloadedBytesHi;// Amount of data downloaded since server start, High 32-bits of 64-bit value
int32_tm_bServerStandBy;// 0 - there are currently downloads running, 1 - no downloads in progress (server paused or all jobs completed)
int32_tm_iNrTrailingEntries;// Number of List-entries, following to this structure
int32_tm_iTrailingDataLength;// Length of all List-entries, following to this structure
// SNZBListResponseEntry m_Entries[m_iNrTrailingEntries]// variable sized
};
===========
New fields are: m_iUpTimeSec, m_iDownloadTimeSec, m_iDownloadedBytesLo, m_iDownloadedBytesHi and m_bServerStandBy. New fields allow client to print that useful info.

Please make required changes in nzbgui.

Best Regards,
hugbug

arieluba

RE: Technical doc & Backward Compatibility

Post by arieluba » 23 Jan 2008, 02:27

Hi hugbug,

I'm working on the new client structures. I wonder if you can add a new message (and we agree not to modify it) that returns the server version (mayor, minor and revision).

This will help me to maintain a multi version client (from 3.1 on)

Thanks

ArielUba



hugbug

RE: Technical doc & Backward Compatibility

Post by hugbug » 23 Jan 2008, 08:35

Hi ArielUba,

Internal version number is just a string, what's why I prefer to return it also as string without parsing on my side. It will return "0.3.0" for current release or "0.3.1-testing" for current svn-code for example. The release 0.3.1 will return "0.3.1". That is exactly the string printed by command "nzbget -v".

The response-structure will be the same as for simple-commands (pause, quit, etc.)

OK?

hugbug.

hugbug

RE: Technical doc & Backward Compatibility

Post by hugbug » 23 Jan 2008, 19:12

The new message has been added.

Post Reply

Who is online

Users browsing this forum: No registered users and 57 guests