Problem 1 For each of the following functionalities, identify the OSI layer it f
ID: 3760866 • Letter: P
Question
Problem 1
For each of the following functionalities, identify the OSI layer it falls under and explain why. a) Data compression; b) Data encryption c) Reverse charging d) File transfers
Problem 2
Identify at least 2 well-known client-server applications that sit on top of UDP. Explain what the service does and the port # it is available on.
Problem 3
TCP stack does not have anything comparable to OSI Level 2 (reliable communication). Does it mean that TCP/IP is deficient? Or whether its absence is compensated by something else. Discuss. Problem 3 Suppose two jobs come in at time 0 and 1 with cpu units 10 and 2. Use FIFO to compute mean turn around time. Will shortest job first (without preemtpion) have a better mean turn around time? Either way explain.
Problem 4
Suppose phyical memory size is 1gbytes. Assume page size = frame size = 4K bytes, and the program size is 32 G bytes. Compute the following. a) # bits needed to specify a virtual page b) # frames in the computer
Explanation / Answer
Problem 1
For each of the following functionalities, identify the OSI layer it falls under and explain why. a) Data compression; b) Data encryption c) Reverse charging d) File transfers
c)Reverse charging: Network layer—This layer translates logical network address and names to MAC addresses for routing data packets over a network. A number of protocols run at the Network layer, including IP, Address Resolution Protocol (ARP), Reverse ARP (RARP), Internet Control Message Protocol (ICMP), Routing Information Protocol (RIP), Open Shortest Path First (OSPF), IGMP, Internetwork Packet Exchange (IPX), NWLink (the Microsoft version of the IPX/SPX protocol suite), and NetBIOS Enhanced User Interface (NetBEUI). Brouters, routers, and some types of ATM switches can be found at this layer of the OSI model.
d) File transfers: Application layer—This layer allows access to network services for applications specifically written to run over the network. Some protocols found at this OSI layer include File Transfer Protocol (FTP), Trivial FTP (TFTP), Bootstrap Protocol (BOOTP), Simple Network Management Protocol (SNMP), Simple Mail Transfer Protocol (SMTP), Telnet, NetWare Core Protocol (NCP), and Server Message Block (SMB) .
Problem 2
Identify at least 2 well-known client-server applications that sit on top of UDP. Explain what the service does and the port # it is available on.
A)SETL provides support for UDP (the User Datagram Protocol). Although this is an ``unreliable'' protocol in that it does not include software mechanisms for retrying on transmission failures or data corruption (unlike TCP), and has restrictions on message length (a little under 65536 bytes), it is needed for applications that use broadcasting or multicasting, and it underlies such important applications as NFS (the Network File System), DNS (the Domain Name System), SNMP (the Simple Network Management Protocol), and various others noted by Stevens [194]. It is also likely to continue to figure prominently in some modern performance-intensive roles such as multimedia.
Strictly speaking, UDP is a ``connectionless'' protocol--a program can use a single UDP socket to communicate with more than one host and port number--but it is convenient for most UDP client programs to maintain the fiction that there is a connection, by keeping a local record of each server host and port number.
This is modeled in SETL by distinguishing between client and server UDP sockets, both in the way the first argument to open is specified and in the operations that are subsequently available on the resulting file descriptor.
To be a UDP client, a program makes a call very similar to what it uses when it asks to be a TCP client: *
fd := open (host_and_port, `udp-client-socket');
The host name and port number in the string form of the first argument here are separated by a colon, just as for TCP. UDP port numbers are entirely independent of TCP port numbers, though the IANA tries to register the same port number for both UDP and TCP when a given service is offered through both protocols. An integer representing an already open UDP client file descriptor is permitted as an alternative to the host_and_port argument, as usual. A successful UDP open makes available the operations *
send (fd, datagram);
where datagram is simply a string, restricted in length as noted above, and *
datagram := recv fd;
which receives a string into datagram. Send and recv are named after the Posix send and recv functions.
The following example program is the UDP analogue of the TCP client with which we began Section 3.1.1 [A Client]: *
fd := open (`galt.cs.nyu.edu:13', `UDP-client-socket');
send (fd, `'); -- send an empty datagram
print (recv fd); -- receive and print a datagram
In the TCP case, opening the connection sufficed to prompt the server to return the desired information (the day of the week and so on), but when a UDP ``connection'' is opened, nothing is actually sent to the server. Even a null string will be wrapped in a UDP packet and sent by send, however, and that prods the server into action in this instance.
A UDP server socket is created in much the same way as a TCP server socket: *
fd := open (port_number, `udp-server-socket');
Again, the port number specified to open is a string of decimal digits. The operations available on this kind of socket are: *
sendto (fd, host_and_port, datagram);
and *
[host_and_port, datagram] := recvfrom fd;
These are also named after the corresponding Posix functions.
Notice that the host name and port number must be specified afresh on every sendto call, and may be returned differently on every recvfrom call--the UDP server socket has no memory of any particular client after passing each datagram.
. Remarkably, it is even simpler: *
fd := open(`50013', `UDP-server-socket');
loop
[whom] := recvfrom fd; -- ignore input datagram
sendto (fd, whom, date); -- send "date" datagram
end loop;
Because a UDP server socket can send and receive data, unlike a TCP server socket (which can only produce new connection sockets using accept), it can actually be used in a client-like role. The following program is functionally equivalent to the very first UDP client example above: *
fd := open (`0', `udp-server-socket');
sendto (fd, `galt.cs.nyu.edu:13', `');
[-, datagram] := recvfrom fd;
print (datagram);
Problem 3
TCP stack does not have anything comparable to OSI Level 2 (reliable communication). Does it mean that TCP/IP is deficient? Or whether its absence is compensated by something else. Discuss.
The design of protocols in the TCP/IP model of the Internet does not concern itself with strict hierarchical encapsulation and layering. RFC 3439 contains a section entitled "Layering considered harmful". TCP/IP does recognize four broad layers of functionality which are derived from the operating scope of their contained protocols: the scope of the software application; the end-to-end transport connection; the internetworking range; and the scope of the direct links to other nodes on the local network.
Despite using a different concept for layering than the OSI model, these layers are nevertheless often compared with the OSI layering scheme in the following way:
These comparisons are based on the original seven-layer protocol model as defined in ISO 7498, rather than refinements in such things as the internal organization of the network layer document.
The presumably strict layering of the OSI model as it is usually described does not present contradictions in TCP/IP, as it is permissible that protocol usage does not follow the hierarchy implied in a layered model. Such examples exist in some routing protocols (e.g., OSPF), or in the description of tunneling protocols, which provide a link layer for an application, although the tunnel host protocol might well be a transport or even an application-layer protocol in its own right.
Related Questions
drjack9650@gmail.com
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.