[Vortex] Any way to interrupt a reply in BEEP?

Francis Brosnan Blazquez francis.brosnan at aspl.es
Wed May 7 20:19:14 CEST 2008


Hi Jens,

> Is there any way in the BEEP protocol to interrupt a lengthy reply?  
> For example, the straightforward way to download a file would be to  
> send a MSG requesting the file, and receive an RPY or multiple ANS  
> frames containing the file contents. But a large file might take a  
> long time to download, and the recipient should be able to cancel  
> partway through. How could that be done?
> 
> The only mechanisms I can think of are:
> 
> (1) Have the file-receiving peer send a message over a different  
> channel, which the file-sending peer will interpret to mean that it  
> should stop sending. (This only works with multiple ANS frames, of  
> course.)
> 
> (2) Have the file-receiving peer close the channel it it wants to
> stop  
> the download.
> 
> (3) Send the download in chunks, with a separate MSG/RPY cycle to  
> fetch each chunk (sort of like a byte-range GET in HTTP.)
> 
> Any thoughts? Did I overlook something? 

No, you didn't Jens.

> Of these, #2 is easiest to  
> implement and doesn't require defining an additional profile for the  
> control messages; but is it OK to close a channel while a reply is  
> still incomplete?

It is possible but tricky. I would suggest to use:

1) MSG/RPY pattern and, if the user cancel the transfer, reply to the
next MSG (and the rest ones) with an ERR message to make the listener
side to stop the transfer. Once the listener receives the first ERR, he
stop, waiting for all pending ERR for all sent MSG.

2) ANS/NUL pattern replying to a client MSG and, if the user cancel,
issue a new MSG on the same channel to stop the download, causing the
listener to issue the final NUL once received the MSG (signaling to
stop).

Both cases would allow you to reuse the channel. First is easy but
second is elegant and would provide you better throughput.

If you don't want to mix in your profile content and commands, create an
control channel, but I wouldn't do that.

Cheers!

> —Jens
-- 
Francis Brosnan Blazquez <francis.brosnan at aspl.es>
Advanced Software Production Line, S.L.




More information about the Vortex mailing list