- General
-
Idées
+63
Add auto-resume to downloading when a forwarding link is broken, then reconnected.
[Retitled for clarity --Moderator]
No resume when broken HF links between CMS via RMS to RMS Express?
Many times (maybe most? or ALL the times?) a broken link transfer seems to start from scratch at next connect. This also when waiting several minutes before the next try so the CMSs should be able to syncronize.
If intention is that the B2F compressed link should catch up from where it had arrived when broke, like the old FBB compressione then there seems to be a bug somewhere.
At the time beeing this again from me is a "feeling" based upon "unsystematic" observations "massaging" the LA3F-5 and LA3F.
Both when doing the Winmor 114kb file on 80m in december several times deliberately "destroing" link it started from scratch every time.
Same observation is done by my Cosysop testing a lot of P1 transfers some days ago in and out of RMS Pactor on 40m using a about 25 kb picture file. It never succeeded. Always stopped a couple of kb before finnished. PK232 on a P1,2,3 capable frequency. Shorter files did succeed.
When getting time for it we will return with Log files from all the sites doing new more systematic obesrvations.
Testing has not been done with Airmail and Paclink.
My hunch is that if there is a bug here, it may be a mission critical one in case of emergency.
Reducing unnecessary footprint is important.
73 de la7um Finn
RMSs la3f, la3f-5, la3f-10
No resume when broken HF links between CMS via RMS to RMS Express?
Many times (maybe most? or ALL the times?) a broken link transfer seems to start from scratch at next connect. This also when waiting several minutes before the next try so the CMSs should be able to syncronize.
If intention is that the B2F compressed link should catch up from where it had arrived when broke, like the old FBB compressione then there seems to be a bug somewhere.
At the time beeing this again from me is a "feeling" based upon "unsystematic" observations "massaging" the LA3F-5 and LA3F.
Both when doing the Winmor 114kb file on 80m in december several times deliberately "destroing" link it started from scratch every time.
Same observation is done by my Cosysop testing a lot of P1 transfers some days ago in and out of RMS Pactor on 40m using a about 25 kb picture file. It never succeeded. Always stopped a couple of kb before finnished. PK232 on a P1,2,3 capable frequency. Shorter files did succeed.
When getting time for it we will return with Log files from all the sites doing new more systematic obesrvations.
Testing has not been done with Airmail and Paclink.
My hunch is that if there is a bug here, it may be a mission critical one in case of emergency.
Reducing unnecessary footprint is important.
73 de la7um Finn
RMSs la3f, la3f-5, la3f-10
Service d'assistance aux clients par UserEcho
the client would sent a Y xxxx The xxxx would be the size of the binary file it saved from the first try for the message with that matching MID.
The CMS would have to be able to skip down to the xxxx byte and start sending at that point and the client has to append the new data onto the file it has in the mail.bin. Seeing that the CMS is sending all binary files from the outside looking in this looks like a great way to save a lot of air time. 73 Steve N9LOH
Working well. (Witout ever been officially planned, hi?) Thanks Phil.
73 de LA7UM Finn
Very good. thank you! this will save a lot of on-air time.
73! Werner oe9fwv
Saving air time is of majour importance in time of real emcomm.
73 and thanks for the effort so far. de LA7UM Finn