1 / 19

UDP File Transfer Nathan Kiel CSE434

UDP File Transfer Nathan Kiel CSE434. Goal. Explore difficulties of UDP transport in a file transfer application Direct experience by writing an FTP style application that uses UDP instead of TCP Gnu C/C++ Run speed tests alongside other applications to compare performance.

roland
Download Presentation

UDP File Transfer Nathan Kiel CSE434

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. UDP File TransferNathan KielCSE434

  2. Goal • Explore difficulties of UDP transport in a file transfer application • Direct experience by writing an FTP style application that uses UDP instead of TCP • Gnu C/C++ • Run speed tests alongside other applications to compare performance

  3. Protocol Differences • TCP - ”Transmission Control Protocol” • ”The” transport protocol for reliable data transfer. • Flow/congestion control, data loss recovery, buffering, all handled by the operating system • Benefits from TCP checksum offloading and higher receive buffers. • UDP - ”User Datagram Protocol” • Data loss, congestion control must be implemented at application layer.

  4. Design Considerations • Number of sockets • 2 sockets like FTP (control and data) • UDP or TCP control socket? • Flow control • What algorithm to handle flow and congestion control? • Multi-threaded • Should the receiver be multi-threaded and why? • Receive loop blocking can delay or lose control packets

  5. Chosen Specifications • UDP control socket and UDP data socket • Problem with UDP control socket? • Single threaded client • Multi-threaded server (control and data) • Window mechanism for flow control • Flow and congestion control managed by the server in a synchronous design • Checksum for data integrity

  6. Design Specs Cont' • Data transmitted in windows of blocks • Block size (in bytes) is determined by (MTU – size_of(all headers)) of packet. • MTU (1500 bytes) – sizeof(IP header) – sizeof (UDP header) – sizeof(UCP header) = 1460 bytes • Window size is determined by server • Client receives 'push' message with offset (in blocks) to transmit window_size # of blocks • Server validates the transfer and forces retransmissions by managing the offset and window size

  7. UCP Headers

  8. Client Flow • Init: • Filename, server IP address on input. • Open control and data sockets. • Send init message to server • File name, file size in bytes, computed block size, total number of bytes • Receive init response from server • Transmit loop • Finish: (Receive 'finish' control message)

  9. Server Flow • Init: • Open control and data sockets. • Receive init control msg from server • Prepare data file • Transmit loop • Send 'push' control messages to client with offset and window size • Receive data, validate with checksum, write to block positions • Finish: (Send 'finish' control message)

  10. Client Transfer Loop • Receive 'push' control message • Learn new offset (starting block position) • Learn new window size • Immediately transmit window_size number of blocks starting at block position = offset • Wait for next 'push' or a 'finish'

  11. Server Transfer Loop • Receives data until entire window_size data is received or until timeout • As data is received scale the timeout downward (starting from high) to shorten the timeout as data is received • Received datat that passes checksum is written directly into the block position in the datafile

  12. Server Transfer Loop Cont' • After a timeout for a receive window • Check all blocks within window for validity • If missing or failed checksum • Set max window size to current window size – scaling factor • Set the offset to the first missing block in window • Prepare next control message with new values • If no missing or failed checksum • Scale window size up by a preset scaling factor • Set offset to previous_offset + previous_window_size • Prepare 'push' control message with new values

  13. Testing Observations • A lost control message (UDP) will stop the transfer completely. • Remedy: Change to a TCP control socket. • Synchronous design affects speed • Client waits for a control message before sending more data. • Remedy: Model TCP

  14. Testing Observations Cont' • Congestion algorithm too simple • Performance is decent under low packet loss conditions • Remedy: Switch to a TCP style model • Remedy: Again synchronous design hurts • Checksum and retransmissions do ensure file integrity. Files pass md5sums after receipt. • Increasing default UDP buffer sizes in the operating system increases performance

  15. Transfer Speed Comparison

  16. Transfer Speed Comparison Cont'

  17. Unlikely to match performance of TCP under average cases TCP checksum offloading Buffer sizes in OS larger for TCP Added complexity in application layer Transport layer in user mode rather than kernel Conclusions • Use a TCP control socket • Use a flow control and congestion control algorithm that mirrors common TCP implementations • Application level receive buffer

  18. References 1: Unknown Author. “Faster Bulk Transfer Starring: UDP.” http://www.csm.ornl.gov/~dunigan/netperf/udp/ 2: Dennis Bush. ”UFTP – A UDP Based FTP with Multicast.” http://www.tcnj.edu/~bush/uftp.html 3: Mythic Beast Lmtd. "VSFTP" http://vsftpd.beasts.org/

More Related