0
W4140 Network Laboratory Lecture 8 Oct 30 - Fall 2006 Shlomo Hershkop Columbia University
Announcements <ul><li>Last lab will be due next week due to hardware issues </li></ul><ul><li>will be working on it </li><...
<ul><li>Here are the group presentations </li></ul>
Virtual Private Networks Gilbert Hom (gch2102@columbia.edu) Mohit Vazirani (mcv2107@columbia.edu) Eric Zhang (ehz2101@colu...
Purpose <ul><li>Learn about how VPNs establish secure channels in a volatile and inherently insecure environment </li></ul...
Phase 1 Goals <ul><li>Set up a VPN server and several VPN clients </li></ul><ul><li>The VPN server will run Windows 2000/2...
Network Setup Router2 E0/0: 10.0.2.2/24 E0/1: 10.0.3.1/24 Hub Server/PC1 E0/0: 10.0.1.11/24 This topology simulates the in...
Tools <ul><li>Windows 2000 Server, Windows XP – Built-in support for VPN connections and firewalls through network configu...
Research Papers <ul><li>M. Blaze, J. Ioannidis, and A. Keromytis. “Trust Management and Network Layer Security Protocols.”...
Man-in-the-middle Attack using ARP Poisoning Arezu Moghadam (amm2141) Armando Ramirez (alr2106) Mark Tabry (met2105)
Project Objective <ul><li>ARP protocol insecure by design </li></ul><ul><li>Possible to impersonate routers/clients </li><...
Phase One Goals <ul><li>Poison ARP caches of router and client </li></ul><ul><li>Set up attacker’s IP forwarding </li></ul...
Phase Two Goals <ul><li>Actively intercept and reply to HTTP requests </li></ul><ul><li>If time, attack other protocols </...
Network Setup I am client I am router To router AP Client Attacker
Network Setup To router AP Client Attacker
Systems and Tools <ul><li>Laptop with Linux kernel (attacker) </li></ul><ul><li>Linux IP forwarding </li></ul><ul><li>Linu...
Research Papers <ul><li>S. Manwani.  ARP cache poisoning prevention and detection.  Technical report, Faculty of Computer ...
Stealing Wireless  HTTPS Auth Casey Callendrello Eric Garrido {cdc2107,ekg2002}@columbia.edu
The Big Idea <ul><li>Use the inherent insecurity in wireless networking to steal passwords. </li></ul><ul><li>Exploit HTML...
What’s the problem with WiFi? <ul><li>You have no idea where your packets are going or where they’re coming from. </li></u...
Phase 1 Goal <ul><li>Using a Linux PC, impersonate an AP </li></ul><ul><li>Intercept traffic and insert HTML exploits.  Us...
Exploit <ul><li>Send a bogus DNS response to a website we control. </li></ul><ul><li>Man in the middle attack </li></ul><u...
Javascript <ul><li>Simply sends us keypresses. </li></ul><ul><li>Posts to same domain as requested site (same origin) or u...
Setup
Extending <ul><li>Ultimate goal: Make TCP Reset attacks work. </li></ul><ul><ul><li>Make attack work from another client. ...
Tools <ul><li>iptables </li></ul><ul><li>http://gnucitizen.org </li></ul><ul><li>dsniff </li></ul><ul><ul><li>dnsspoof </l...
W 4140 Networking Laboratory  Final Project: Wireless Network
Team Member <ul><li>Matt (Yu-Ming Chang)  </li></ul><ul><ul><li>[email_address] </li></ul></ul><ul><li>Yitao Wang </li></u...
<ul><li>Problem to be solved in this project: How to choose from the a  access point with higher bandwidth? </li></ul>
The Goal of Phase I <ul><li>Set up experimental environment. </li></ul><ul><ul><li>Install and configure 2 wireless adapte...
 
Analysis tools <ul><li>iperf (end-to-end bandwidth measurement tool) voip clients such as yate  http:// yate.null.ro  and ...
Reference <ul><li>http://vtun.sourceforge.net/tun/faq.html </li></ul><ul><li>http://yate.null.ro/pmwiki/index.php?n=Main.W...
MiniDoS: Denial of Service Attacks Over Small Networks Al Hwang (ah2200) Mike Lynch (mtl2103) Cindy Liao (cl2229)
Project Objective <ul><li>Investigate the resilience of network equipment and hosts against denial of service attacks in a...
Phase 1 Goals <ul><li>Research different types of DoS attacks: </li></ul><ul><ul><li>SYN Floods, ACK Floods, ICMP Flood, S...
Network Topology Hub Router1 Router2 Router3 hub hub hub PC 4 (Master) PC 2 (Zombie) PC 1 PC 3 (Zombie)
Tools <ul><li>We will look into various published malicious tools to employ these attacks, including: </li></ul><ul><ul><l...
Research Papers <ul><li>Security Analyses by Dr. David Dittrich  (University of Washington): </li></ul><ul><ul><li>“ The ‘...
Research Papers (cont’d) <ul><li>“ DDoS Attacks and Defense Mechanisms: Classification and State-of-the-art” by Christos D...
Project Outline/Proposal for : Project 3: Resilience of network equipment and hosts against Denial of Service Attacks (DoS)
Group composition   <ul><li>Roberto Martin ( [email_address] ) </li></ul><ul><li>Darren Tang (tt2191@columbia.edu) </li></ul>
Main point of the entire project   <ul><li>The question we are trying to answer is: how resilient are networks against the...
Phase 1 goals   <ul><li>Phase1 (network level attacks)  </li></ul><ul><li>As the project outline states this will involve ...
Network Topology 1
Network Topology 2
Tools being used   <ul><li>Ethereal (to view packets) </li></ul><ul><li>Ettercap (arp poisoning/spoofing) </li></ul>
Resources <ul><li>[1]  Jelena Mirkovic, Sven Dietrich, David Dittrich, Peter Reiher.  </li></ul><ul><li>Internet Denial of...
Defence Mechanisms <ul><li>1. Use static ARP tables between important hosts (not very practical in most cases). 2. Use ARP...
Securing Networks and Communications VPN and Firewall Setup and Configuration Sharmini Ilankovan [email_address] Sharmisth...
Goal of the project <ul><li>To study implementations and setup of VPN and Firewalls  </li></ul><ul><li>To implement any me...
Phase I Objective <ul><li>To study literature and man pages for implementation and setup of mechanisms used in VPN for Win...
Network setup <ul><li>Source machine </li></ul><ul><li>Destination machine </li></ul><ul><li>The path between the two will...
Tools required for implementation <ul><li>Implement random routing between the two end hosts with data encryption </li></u...
References <ul><li>http://www.onion-router.net </li></ul><ul><li>Publication:Onion Routing for Anonymous and Private Inter...
Linux Kernel 2.6 Support for Overlay Networks
Introduction <ul><li>Objective of the project: </li></ul><ul><li>Reduce Application Layer / Kernel Layer switching latency...
Breakup of Tasks <ul><li>Phase 1:  (Classification / Marking / Queuing of IP datagrams based on type)  </li></ul><ul><li>G...
Classification / Marking / Queuing and scheduling of IP Datagrams NF_IP_LOCAL_OUT (imeplement the kernel hooks here to cla...
<ul><li>Phase 1: </li></ul><ul><li>Group : 2  </li></ul><ul><li>(Implementation of kernel hooks to bypass user space / ker...
<ul><li>System Call – peer_send() / peer_recv() </li></ul><ul><li>peer_send() : System call to bypass the socket API send ...
<ul><li>System Call – peer_send() / peer_recv() </li></ul><ul><li>peer_send() :  </li></ul><ul><li>peer_send(sockfd, filen...
<ul><li>System Call – peer_send() / peer_recv() </li></ul><ul><li>peer_recv() :  </li></ul><ul><li>peer_recv(sockfd, filen...
<ul><li>Any Questions? </li></ul>
Upcoming SlideShare
Loading in...5
×

Group Projects Phase I

323

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
323
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • The TUN is Virtual Point-to-Point network device.  TUN driver was designed as low level kernel support for  IP tunneling. It provides to userland application  two interfaces:    - /dev/tunX - character device;    - tunX - virtual Point-to-Point interface.   Userland application can write IP frame to /dev/tunX  and kernel will receive this frame from tunX interface.  In the same time every frame that kernel writes to tunX  interface can be read by userland application from /dev/tunX  device. Yate is a next-generation telephony engine; while currently focused on Voice over Internet Protocol (VoIP) and PSTN , its power lies in its ability to be easily extended. Voice, video, data and instant messaging can all be unified under Yate&apos;s flexible routing engine, maximizing communicationsefficiency and minimizing infrastructure costs for businesses.
  • Transcript of "Group Projects Phase I"

    1. 1. W4140 Network Laboratory Lecture 8 Oct 30 - Fall 2006 Shlomo Hershkop Columbia University
    2. 2. Announcements <ul><li>Last lab will be due next week due to hardware issues </li></ul><ul><li>will be working on it </li></ul><ul><li>today: Group presentations </li></ul><ul><ul><li>please save questions for end </li></ul></ul><ul><ul><li>if you have an idea, please share </li></ul></ul><ul><ul><li>need to coordinate between groups/racks </li></ul></ul>
    3. 3. <ul><li>Here are the group presentations </li></ul>
    4. 4. Virtual Private Networks Gilbert Hom (gch2102@columbia.edu) Mohit Vazirani (mcv2107@columbia.edu) Eric Zhang (ehz2101@columbia.edu)
    5. 5. Purpose <ul><li>Learn about how VPNs establish secure channels in a volatile and inherently insecure environment </li></ul><ul><li>Explore VPN options in Windows and Linux and learn about how different implementations interact </li></ul>
    6. 6. Phase 1 Goals <ul><li>Set up a VPN server and several VPN clients </li></ul><ul><li>The VPN server will run Windows 2000/2003 Server; the clients will run Windows XP </li></ul><ul><li>Observe traffic flow and encryption between machines with Ethereal/tcpdump </li></ul>
    7. 7. Network Setup Router2 E0/0: 10.0.2.2/24 E0/1: 10.0.3.1/24 Hub Server/PC1 E0/0: 10.0.1.11/24 This topology simulates the internet: The server and clients are on different subnets, and there may be multiple paths available to the server from the client. Router3 E0/0: 10.0.2.3/24 E0/1: 10.0.3.2/24 Router1 E0/0: 10.0.1.1/24 E0/1: 10.0.2.1/24 Hub Router4 E0/0: 10.0.3.4/24 E0/1: 10.0.4.1/24 PC2 E0/0: 10.0.4.2/24 PC4 E0/0: 10.0.4.3/24 PC3 E0/0: 10.0.4.4/24
    8. 8. Tools <ul><li>Windows 2000 Server, Windows XP – Built-in support for VPN connections and firewalls through network configuration options </li></ul><ul><li>Linux – Openswan (Open source IPsec implementation for Linux) for VPN and iptables for firewalling </li></ul><ul><li>Ethereal – To monitor network traffic and verify that the communication is encrypted. </li></ul><ul><li>OpenSSL – To generate certificates needed for authentication. </li></ul>
    9. 9. Research Papers <ul><li>M. Blaze, J. Ioannidis, and A. Keromytis. “Trust Management and Network Layer Security Protocols.” In Proceedings of the 1999 Cambridge Security Protocols International Workshop, 1999. http://citeseer.ist.psu.edu/643312.html </li></ul><ul><li>R. Gawlick, C. Kamanek, and K.G. Ramakrishnan. “On-line routing for virtual private networks.” Unpublished manuscript, February 1994. http://citeseer.ist.psu.edu/186679.html </li></ul>
    10. 10. Man-in-the-middle Attack using ARP Poisoning Arezu Moghadam (amm2141) Armando Ramirez (alr2106) Mark Tabry (met2105)
    11. 11. Project Objective <ul><li>ARP protocol insecure by design </li></ul><ul><li>Possible to impersonate routers/clients </li></ul><ul><li>Nature of wireless networks compound the problem </li></ul><ul><li>Inject our attacker between client and router, and manipulate traffic </li></ul>
    12. 12. Phase One Goals <ul><li>Poison ARP caches of router and client </li></ul><ul><li>Set up attacker’s IP forwarding </li></ul><ul><li>Man-in-the-middle without analysis or data manipulation </li></ul>
    13. 13. Phase Two Goals <ul><li>Actively intercept and reply to HTTP requests </li></ul><ul><li>If time, attack other protocols </li></ul>
    14. 14. Network Setup I am client I am router To router AP Client Attacker
    15. 15. Network Setup To router AP Client Attacker
    16. 16. Systems and Tools <ul><li>Laptop with Linux kernel (attacker) </li></ul><ul><li>Linux IP forwarding </li></ul><ul><li>Linux library for packet construction </li></ul><ul><ul><li>libnet? </li></ul></ul><ul><li>Interest Lab Access Point/Client </li></ul><ul><li>Network Sniffer </li></ul><ul><ul><li>Ethereal </li></ul></ul>
    17. 17. Research Papers <ul><li>S. Manwani. ARP cache poisoning prevention and detection. Technical report, Faculty of Computer Science, San Jose State University, December 2003. </li></ul>
    18. 18. Stealing Wireless HTTPS Auth Casey Callendrello Eric Garrido {cdc2107,ekg2002}@columbia.edu
    19. 19. The Big Idea <ul><li>Use the inherent insecurity in wireless networking to steal passwords. </li></ul><ul><li>Exploit HTML vulnerabilities to silently grab passwords. </li></ul>
    20. 20. What’s the problem with WiFi? <ul><li>You have no idea where your packets are going or where they’re coming from. </li></ul><ul><ul><li>Anybody can name their AP “Columbia University” </li></ul></ul>
    21. 21. Phase 1 Goal <ul><li>Using a Linux PC, impersonate an AP </li></ul><ul><li>Intercept traffic and insert HTML exploits. Use these to capture passwords </li></ul><ul><li>Two “exploit vectors” </li></ul><ul><ul><li>DNS hijacking </li></ul></ul><ul><ul><li>Man-in-the-middle HTML injection </li></ul></ul>
    22. 22. Exploit <ul><li>Send a bogus DNS response to a website we control. </li></ul><ul><li>Man in the middle attack </li></ul><ul><ul><li>Send a TCP reset to the server </li></ul></ul><ul><ul><li>Send traffic to the client with our exploit </li></ul></ul>
    23. 23. Javascript <ul><li>Simply sends us keypresses. </li></ul><ul><li>Posts to same domain as requested site (same origin) or uses trickery*. </li></ul>* - Signed code, DNS Pinning attack, etc.
    24. 24. Setup
    25. 25. Extending <ul><li>Ultimate goal: Make TCP Reset attacks work. </li></ul><ul><ul><li>Make attack work from another client. </li></ul></ul>
    26. 26. Tools <ul><li>iptables </li></ul><ul><li>http://gnucitizen.org </li></ul><ul><li>dsniff </li></ul><ul><ul><li>dnsspoof </li></ul></ul><ul><ul><li>webmitm </li></ul></ul>
    27. 27. W 4140 Networking Laboratory Final Project: Wireless Network
    28. 28. Team Member <ul><li>Matt (Yu-Ming Chang) </li></ul><ul><ul><li>[email_address] </li></ul></ul><ul><li>Yitao Wang </li></ul><ul><ul><li>[email_address] </li></ul></ul><ul><li>Alexandre Ling Lee </li></ul><ul><ul><li>[email_address] </li></ul></ul>
    29. 29. <ul><li>Problem to be solved in this project: How to choose from the a access point with higher bandwidth? </li></ul>
    30. 30. The Goal of Phase I <ul><li>Set up experimental environment. </li></ul><ul><ul><li>Install and configure 2 wireless adapter on one laptop </li></ul></ul><ul><ul><li>Set up 2 access points </li></ul></ul><ul><ul><li>Build the network between the adapters and APs, analysis the traffic by looking into the captured packets </li></ul></ul>
    31. 32. Analysis tools <ul><li>iperf (end-to-end bandwidth measurement tool) voip clients such as yate http:// yate.null.ro and the tools from Hennings web page for path measurement and characterization for VoIP. </li></ul><ul><li>Also, read about how 802.11a/b/g LAN/MAN Wireless standard works and some papers about multipath routing and tun http:// vtun.sourceforge.net/tun / </li></ul>
    32. 33. Reference <ul><li>http://vtun.sourceforge.net/tun/faq.html </li></ul><ul><li>http://yate.null.ro/pmwiki/index.php?n=Main.WhatsYate? </li></ul>
    33. 34. MiniDoS: Denial of Service Attacks Over Small Networks Al Hwang (ah2200) Mike Lynch (mtl2103) Cindy Liao (cl2229)
    34. 35. Project Objective <ul><li>Investigate the resilience of network equipment and hosts against denial of service attacks in a small network. </li></ul><ul><li>To do this, we will existing malicious networking tools to </li></ul>
    35. 36. Phase 1 Goals <ul><li>Research different types of DoS attacks: </li></ul><ul><ul><li>SYN Floods, ACK Floods, ICMP Flood, Smurf Attacks </li></ul></ul><ul><li>Testing attacks and documenting resilience of target hosts </li></ul><ul><li>Analyze means to improve effectiveness of attack. </li></ul>
    36. 37. Network Topology Hub Router1 Router2 Router3 hub hub hub PC 4 (Master) PC 2 (Zombie) PC 1 PC 3 (Zombie)
    37. 38. Tools <ul><li>We will look into various published malicious tools to employ these attacks, including: </li></ul><ul><ul><li>mstream – primitive tool, contains errors, but still causes significant disruption to network </li></ul></ul><ul><ul><li>trinoo – employs SYN attacks with encrypted communications between master and zombie attackers </li></ul></ul><ul><ul><li>TFN (Tribe Flood Network) – advanced tool that implements a number of different DoS attack methods </li></ul></ul>
    38. 39. Research Papers <ul><li>Security Analyses by Dr. David Dittrich (University of Washington): </li></ul><ul><ul><li>“ The ‘mstream’ Distributed Denial of Service Attack Tool” ( http://staff.washington.edu/dittrich/misc/mstream.analysis.txt ) </li></ul></ul><ul><ul><li>“ The DoS Project's ‘trinoo’ Distributed Denial of Service Attack Tool” ( http://staff.washington.edu/dittrich/misc/trinoo.analysis.txt ) </li></ul></ul><ul><ul><li>“ The ‘Tribe Flood Network’ Distributed Denial of Service Attack Tool” ( http:// staff.washington.edu/dittrich/misc/tfn.analysis.txt ) </li></ul></ul>
    39. 40. Research Papers (cont’d) <ul><li>“ DDoS Attacks and Defense Mechanisms: Classification and State-of-the-art” by Christos Douligeris and Aikaterini Mitrokotsa (Oct. 13, 2003) </li></ul><ul><ul><li>Overview of DDoS attacks in general and concepts involved in preventing them </li></ul></ul>
    40. 41. Project Outline/Proposal for : Project 3: Resilience of network equipment and hosts against Denial of Service Attacks (DoS)
    41. 42. Group composition <ul><li>Roberto Martin ( [email_address] ) </li></ul><ul><li>Darren Tang (tt2191@columbia.edu) </li></ul>
    42. 43. Main point of the entire project <ul><li>The question we are trying to answer is: how resilient are networks against the DOS attacks (as will be defined)? </li></ul>
    43. 44. Phase 1 goals <ul><li>Phase1 (network level attacks) </li></ul><ul><li>As the project outline states this will involve Arp poisoning attacks and also router resilience to packet fragmentation and address spoofing. We will take the following approach to investigate these attacks: </li></ul><ul><li>Arp Poisoning </li></ul><ul><ul><li>First we will clearly define what this means and investigate exactly how it is done. From this information we will gather all the tools needed to carry out such an attack, then we will experiment with this in the lab and observe the resilience of the switches. </li></ul></ul><ul><li>Address Spoofing </li></ul><ul><ul><li>Again we will clearly define what this means and as above gather tools needed to carry out and measure the effects of such attacks. </li></ul></ul>
    44. 45. Network Topology 1
    45. 46. Network Topology 2
    46. 47. Tools being used <ul><li>Ethereal (to view packets) </li></ul><ul><li>Ettercap (arp poisoning/spoofing) </li></ul>
    47. 48. Resources <ul><li>[1] Jelena Mirkovic, Sven Dietrich, David Dittrich, Peter Reiher. </li></ul><ul><li>Internet Denial of Service: Attack and </li></ul><ul><li>Defense Mechanisms, Prentice Hall, 2005. </li></ul><ul><li>[2] Ettercap Web Page: http:// ettercap.sourceforge.net / </li></ul><ul><li>[ 3 ] Ed Skoudis, Tom Liston </li></ul><ul><li>Counter Hack Reloaded </li></ul>
    48. 49. Defence Mechanisms <ul><li>1. Use static ARP tables between important hosts (not very practical in most cases). 2. Use ARPWatch to spot when someone is pulling off an ARP poisoning attack. </li></ul>
    49. 50. Securing Networks and Communications VPN and Firewall Setup and Configuration Sharmini Ilankovan [email_address] Sharmistha Roy [email_address] KaoFu Lai [email_address]
    50. 51. Goal of the project <ul><li>To study implementations and setup of VPN and Firewalls </li></ul><ul><li>To implement any mechanism of secure communications and test it </li></ul>
    51. 52. Phase I Objective <ul><li>To study literature and man pages for implementation and setup of mechanisms used in VPN for Windows machines </li></ul><ul><li>To implement a version of Onion Routing mechanism (one method for anonymous communications) </li></ul>
    52. 53. Network setup <ul><li>Source machine </li></ul><ul><li>Destination machine </li></ul><ul><li>The path between the two will consist of routers forwarding the packets to the hosts. A layer of encryption is added for each router in the path and each router decrypts the layer as a packet reaches it </li></ul>
    53. 54. Tools required for implementation <ul><li>Implement random routing between the two end hosts with data encryption </li></ul><ul><li>Implement Privoxy Filter to conceal the identity of client visiting a server website </li></ul>
    54. 55. References <ul><li>http://www.onion-router.net </li></ul><ul><li>Publication:Onion Routing for Anonymous and Private Internet connections: David GoldSchlag,Michael Reed,Paul Syverson </li></ul>
    55. 56. Linux Kernel 2.6 Support for Overlay Networks
    56. 57. Introduction <ul><li>Objective of the project: </li></ul><ul><li>Reduce Application Layer / Kernel Layer switching latency due to standard socket API system call </li></ul><ul><li>Reduce Indirection Delay induced due to the inherent indirection infrastructure of the modern overlay networks and achieve better network characteristics such as low latency, high bandwidth etc. </li></ul><ul><li>Support packet classification and scheduling for providing QoS guarantees </li></ul>
    57. 58. Breakup of Tasks <ul><li>Phase 1: (Classification / Marking / Queuing of IP datagrams based on type) </li></ul><ul><li>Group : 1 </li></ul><ul><li>(Aniruddha , Ankur , Dhruva) </li></ul><ul><li>- Linux Packet Scheduling , Queuing , </li></ul><ul><li>- Tools to queue and mark packets (eg. NF- </li></ul><ul><li>HiPAC, ipset etc.) </li></ul><ul><li>- Testing out simple P2P application and </li></ul><ul><li>assuring QoS for such applications using such packet marking queuing mechanism </li></ul>
    58. 59. Classification / Marking / Queuing and scheduling of IP Datagrams NF_IP_LOCAL_OUT (imeplement the kernel hooks here to classify / mark and queue IP datagrams
    59. 60. <ul><li>Phase 1: </li></ul><ul><li>Group : 2 </li></ul><ul><li>(Implementation of kernel hooks to bypass user space / kernel space switching) </li></ul><ul><li>(Sambuddho , Tarun) </li></ul><ul><li>- Design and implementation of the system call to directly send the file </li></ul><ul><li>across to the peer host </li></ul><ul><li> - Design and implementation of the </li></ul><ul><li>system call to directly receive the file </li></ul><ul><li>across to the peer host </li></ul>
    60. 61. <ul><li>System Call – peer_send() / peer_recv() </li></ul><ul><li>peer_send() : System call to bypass the socket API send () / sendto () and directly pass the file name to the kernel </li></ul><ul><li>peer_recv () : System call to bypass the kernel recv() / recvfrom() system call and directly get the filename to write to. This should be a blocking system call which blocks till the file is received and copied into the file. </li></ul>
    61. 62. <ul><li>System Call – peer_send() / peer_recv() </li></ul><ul><li>peer_send() : </li></ul><ul><li>peer_send(sockfd, filename,sock_param); </li></ul><ul><li>do_peer_send(sockfd, filename,sock_param){ </li></ul><ul><li>/* open the file and mmap() it to a kernel space </li></ul><ul><li>block of memory and then call the actual UDP/IP stack operations to transfer the file */ </li></ul><ul><li>} </li></ul>(User space) (Kernel space)
    62. 63. <ul><li>System Call – peer_send() / peer_recv() </li></ul><ul><li>peer_recv() : </li></ul><ul><li>peer_recv(sockfd, filename,sock_param); </li></ul><ul><li>` </li></ul><ul><li>do_peer_recv(sockfd, filename,sock_param){ </li></ul><ul><li>/* read multiple blocks of data from the sockfd socket and buffer them to a block of kernel memory and when the block is full transfer it to a file and then again call the actual UDP/IP stack operations to receive the next block of memory of the file */ </li></ul><ul><li>} </li></ul>(User space) (Kernel space)
    63. 64. <ul><li>Any Questions? </li></ul>
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×