2011/5/2 Saúl Ibarra Corretgé <[email protected]>: > Lets say we transfer file test.iso from Alice to Bob. Bob will > acknowledge the reception of every chunk of data just fine. Since I/O > operations usually take time to complete, we don't send the 200 to a > SEND when actual bytes are written, but when the chunk is received > over the network.
It is specified nowhere that received bytes must be written to a file, or to a DB or whatever, so the protocol can only assert the receipt of the bytes from the network. > While the file transfer is in progress the disk becomes full because > some backup process kicked in and bytes can no longer be written to > disk. Or, the hard drive is faulty and after assembling all the chunks > together, the resulting hash differs from the original one. Either > way, this fail transfer didn't end well even if all chunks were > correctly sent and received over the wire. > > Is there any standard mechanism to overcome this situations? I > couldn't find anything I could use on RFC 4975 nor RFC 5547. I guess > something like a 'final status report' would do. Is there such a thing > specified anywhere that I missed? This is like when you send a mail. The SMTP protocol just asserts you that the mail has been received in the destination server, but you have no way to determine if it has been delivered to the final user (let's forget mail-receipt-configuration features, who uses that?). So IMHO, at SIP/MSRP protocol your scenario is working correctly. It's not MSRP business the final usage/storage of the received data (and it must not be). I assume that your SIP device should warn the user about the loss or corruption of the received data (but again, it has nothing to do with MSRP). -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
