Technical doc & Backward Compatibility

Get help, report and discuss bugs.
arieluba

Technical doc & Backward Compatibility

Post by arieluba » 12 Dec 2007, 15:04

Hi everybody,

Thanks to all developers for all the improvements that have made to NZBGet 0.3
I'm going to update nzbgui in order to be compliant with this new version.

I'm wondering if you can give me some technical information about messages between the client and server. That will definitely help me to adapt nzbgui and will reduce the amount of nzbget code that I have to read.

Second, I've realize that this new version protocol is not compatible with the previous one. There is no problem, but I think that it would be better if from now on we try to maintain backward compatibility. In that way we will able to continue using all the related software.

Thanks in advance

ArielUba

hugbug

RE: Technical doc & Backward Compatibility

Post by hugbug » 12 Dec 2007, 20:34

Hi ArielUba,
thank you for your interest and participation.

The compatibility of communication protocol is currently an issue.
As long as the version 0.2.3 was not used widely anymore I did not care about compatibility.

But the protocol was changed not only in version 0.3.0, there was another substantial change after release already.

After version 0.3.0 was published, I found, that neither previous developers nor I did pay an attention to the fact, that endianness affects data transmitted over network. The clients and servers of version 0.3.0 are compatible only if they use the same endianness. For example x86 and mipsell are both little endian, it works. ARM-processors can work in two modes (little and big endian), depending on OS used.

This compatibility issue was addressed and already fixed in source code (svn-repository), but a new release (probably 0.3.1) is not published yet. Providing compatibility with protocol 0.3.0 means a lot of work, which I did not want to do, since nzbget is the only program, using its protocol.

From now on I will try to provide compatibility with protocol 0.3.1, if it would be extended in later versions.

Please implement protocol 0.3.1 in nzbgui. You need to get the latest version from svn. I could sent you a compiled win32-version, if you want.

The protocol messages and structures are defined in MessageBase.h. Units RemoteServer.cpp and RemoteClient.cpp could be used as examples, where RemoteClient.cpp should be most interesting for you.

Best Regards,
hugbug.

hugbug

RE: Technical doc & Backward Compatibility

Post by hugbug » 13 Dec 2007, 10:28

I have just added comments for every field in MessageBase.h.
Please take the last version from svn.

nobody

RE: Technical doc & Backward Compatibility

Post by nobody » 13 Dec 2007, 15:28

Hi hugbug,
Thanks for the comments.
I wonder if you can use 64bits for file size (in SNZBListRequestAnswerEntry message), because 32 bits is really short (nowadays)
124 uint32_tm_iFileSize;// Filesize in bytes
126 uint32_tm_iRemainingSize;// Remaining Filesize in bytes

Thanks

ArielUba

hugbug

RE: Technical doc & Backward Compatibility

Post by hugbug » 13 Dec 2007, 19:17

OK, I've changed them to 64-bits, but 32 bits were not a problem anyway, since files in usenet are usually not bigger than 100MB.
I've used this opportunity to change other structures in order to provide more clear interface (more logical field order and names).
Please update from svn.

I'm also going to change the structure SNZBEditQueueRequest to make it possible to affect multiple not sequential items at one time. This should be very useful in your GUI application.

I'll keep you informed.

hugbug

RE: Technical doc & Backward Compatibility

Post by hugbug » 14 Dec 2007, 00:23

@ALL:
The Edit-Command (and structure SNZBEditQueueRequest) was updated.

Now it is possible to pass several file IDs at once and switch "-I" is not needed anymore, e.g.:

nzbget -E P 6-7,10,22-49

The file IDs can be also separated with spaces, e.g.:

nzbget -E P 6-7 10 22-49

The reverse order of IDs in a range can be also used. This allows to keep relative order of files by moving items to the beginning of queue, since edit-command now processes files in a giving order:

nzbget -E T 10-1

NOTE: these changes refer to the code in svn, not to the latest release (0.3.0) in the Files-Section.



@ArielUba:
I think I'm done with changes to protocol, unless you ask for another change.
Please let me know:
1) if you need a tester for your program. I would be happy to check it.
2) when you will be ready to publish it. I will publish nzbget-0.3.1 then.

Best Regards,
hugbug.

merlum

RE: Technical doc & Backward Compatibility

Post by merlum » 14 Dec 2007, 12:19

I am OK to test and review the adapted nzbgui too.
ArielUba, did you look at my modifications I sent to you last week? It was working with the 0.3.0 version of nzbget.
To do that rapidly, I used ethereal to sniff datagrams between nzbget server and client. This method speeded up my understanding on the structures in nzbget.

Thierry

nobody

RE: Technical doc & Backward Compatibility

Post by nobody » 14 Dec 2007, 16:15

Hi Thierry,
I've take a quick look to the modifications you sent me, and the seems fine. Unfortunately, I was already working (on the cvs) on the protocol for the new version (I guess 0.3.1) and on the new features.
I don't know when the next NZBGet version 'll be launched, but if it's schedule in the short term I'm not going to release a nzbgui version compatible with 0.3.0.

hugbug, can you tell me when you are planning to launch the next nzbget version?

Thanks

arieluba

RE: Technical doc & Backward Compatibility

Post by arieluba » 14 Dec 2007, 16:17

Ups, I forgot to log in.
I'm arielUba

arieluba

RE: Technical doc & Backward Compatibility

Post by arieluba » 14 Dec 2007, 16:26

Hi hugbug,
I have one request more. I'd really like to add a new message for adding new nzb files to the queue, but instead of taking the file path, carrying the file content. This will allow us to add files to the queue from another computer.
I'd like to know your opinion about it.

Best Regards,
ArielUba


86 struct SNZBDownloadRequest
87 {
88 SNZBMessageBasem_MessageBase;// Must be the first in the struct
89 charm_szFilename[ NZBREQUESTFILENAMESIZE ];// Name of nzb-file, may contain full path (local path on client) or only filename
90 uint32_tm_bAddFirst;// 1 - add file to the top of download queue
91 uint32_tm_iTrailingDataLength;// Length of nzb-file in bytes
92 };

Post Reply

Who is online

Users browsing this forum: No registered users and 55 guests