iiiiiiiiiiiiiiiiiiiiii iiiiiiiiiii

iiiiiiiiiiiiiiiiiiii

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii INTERNAL i iASSIGNMENT

NAME i: iROHIT iSHARMA

ROLL iNO i: i2214509351
SUBJECT iNAME i: iCOMPUTER iNETWORKING
SUBJECT iCODE i: iDCA2201
SEMESTER i: i4TH
SESSION i: iAPRIL i2024
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii SET-1

[Link] i1 iDescribe ithe iTCP/IP iprotocol isuite iand iits irelationship iwith ithe iTCP/IP
imodel. iDiscuss ithe ifour ilayers iof ithe iTCP/IP imodel i(Network iInterface,

iInternet, iTransport, iand iApplication ilayers), iexplaining ithe irole iof ieach ilayer iin

ithe itransmission iof idata iacross inetworks. iCompare ithe iTCP/IP imodel iwith ithe

iOSI imodel, ihighlighting isimilarities iand idifferences.

ANS i i iThe iTCP/IP iprotocol isuite iis ia iset iof icommunication iprotocols iused ifor
ithe iInternet iand isimilar inetworks. iIt iis ithe ifoundation iof iall iInternet
icommunications iand iis ibased ion ithe iTCP/IP imodel, ia iconceptual iframework
ithat ioutlines ihow idifferent iprotocols iinteract ito ienable inetwork

icommunication.

The iFour iLayers iof ithe iTCP/IP iModel

1. Network iInterface iLayer

o Role: iThis ilayer iis iresponsible ifor ithe iphysical itransmission iof idata
iover ia inetwork imedium. iIt iincludes iprotocols ithat ideal iwith

ihardware iaddressing iand ilow-level icommunication.

o Functions: iDefines ihow idata iis isent iphysically ithrough ithe

inetwork. iHandles ithe iinterface iwith ithe iphysical inetwork

ihardware i(e.g., iEthernet, iWi-Fi).

o Protocols: iEthernet, iWi-Fi i(IEEE i802.11), iARP i(Address iResolution

iProtocol).

2. Internet iLayer
o Role: iThis ilayer ihandles ithe ilogical itransmission iof idata iover ithe
ientire inetwork. iIt iis iresponsible ifor iaddressing, irouting, iand

ipackaging idata ipackets.

o Functions: iProvides ilogical iaddressing i(IP iaddresses) iand irouting

iof idata ipackets. iEnsures idata ipackets iare irouted ifrom ithe isource

ito ithe idestination, ieven iacross imultiple inetworks.

o Protocols: iIP i(Internet iProtocol), iICMP i(Internet iControl iMessage

iProtocol), iIGMP i(Internet iGroup iManagement iProtocol).

3. Transport iLayer
o Role: iThis ilayer iprovides iend-to-end icommunication iservices ifor
iapplications. iIt iensures ithat idata iis itransferred ireliably iand ierror-

free ibetween ithe isource iand idestination.

o Functions: iHandles ierror idetection iand icorrection, iflow icontrol,
iand iensures idata iis idelivered iin ithe icorrect isequence. iProvides

imechanisms ifor imultiplexing iand idemultiplexing idata ifrom

idifferent iapplications.

o Protocols: iTCP i(Transmission iControl iProtocol), iUDP i(User

iDatagram iProtocol).

4. Application iLayer
o Role: iThis ilayer iprovides iprotocols iand iservices idirectly iused iby
iapplications ito icommunicate iover ithe inetwork.

o Functions: iDefines iprotocols ifor ispecific idata icommunication

iservices ion ia iprocess-to-process ilevel, iincluding iemail, ifile

itransfer, iand iweb ibrowsing.

 o Protocols: iHTTP i(Hypertext iTransfer iProtocol), iFTP i(File iTransfer
iProtocol), iSMTP i(Simple iMail iTransfer iProtocol), iDNS i(Domain

iName iSystem).

Comparison iwith ithe iOSI iModel

The iOSI i(Open iSystems iInterconnection) imodel iis ianother iconceptual

iframework iused ito iunderstand inetwork iinteractions. iIt iconsists iof iseven

ilayers, icompared ito ithe ifour ilayers iof ithe iTCP/IP imodel.

OSI iModel iLayers

1. Physical iLayer
2. Data iLink iLayer
3. Network iLayer
4. Transport iLayer
5. Session iLayer
6. Presentation iLayer
7. Application iLayer

Similarities

• Both imodels iare ilayered iframeworks iused ito iunderstand iand idesign
inetwork iprotocols.

• Both iprovide ia istructure ito istandardize inetworking iprotocols iand

ifacilitate iinteroperability.

Differences

1. Number iof iLayers:

o OSI imodel ihas iseven ilayers, iwhile ithe iTCP/IP imodel ihas ifour
ilayers.

2. Layer iFunctions:
o Application iLayer: iIn ithe iOSI imodel, ithere iare ithree iseparate
ilayers i(Application, iPresentation, iSession) icorresponding ito ithe

iTCP/IP iApplication ilayer.

o Transport iLayer: iBoth imodels ihave ia iTransport ilayer iwith isimilar

ifunctions.

o Network/Internet iLayer: iOSI's iNetwork ilayer icorresponds ito

iTCP/IP's iInternet ilayer.
 o Network iInterface/Physical iand iData iLink iLayers: iTCP/IP icombines
iOSI's iPhysical iand iData iLink ilayers iinto ia isingle iNetwork iInterface

ilayer.

3. Development iand iUsage:

o The iOSI imodel iwas ideveloped ias ia itheoretical iframework iand iis
iless icommonly iimplemented iin ipractice.

o The iTCP/IP imodel iwas ideveloped ibased ion ithe iprotocols iused iin
ithe iARPANET iand iis ithe ifoundation ifor ithe iInternet.

[Link] i2 iExplain ithe iconcept iof isliding iwindow iprotocols iin icomputer
inetworking. iCompare iand icontrast ithe itwo imain itypes iof isliding iwindow

iprotocols: iStop-and-Wait iand iGo-Back-N. i

ANS i iSliding iwindow iprotocols iare ia imethod iused iin icomputer inetworking ito
icontrol ithe iflow iof idata ibetween itwo idevices, iensuring ireliable iand iefficient

itransmission. iThey imanage ithe iamount iof idata ithat ican ibe isent ibefore

ineeding ian iacknowledgment ifrom ithe ireceiver. iSliding iwindow iprotocols ihelp

ioptimize ithe iuse iof inetwork iresources, ireduce icongestion, iand iimprove

ithroughput.

Concept iof iSliding iWindow iProtocols

In isliding iwindow iprotocols, iboth ithe isender iand ireceiver imaintain ia iwindow
ithat irepresents ithe irange iof isequence inumbers ifor ipackets ithat iare iallowed ito

ibe isent ior ireceived. iThe isize iof ithe iwindow idetermines ithe inumber iof ipackets

ithat ican ibe isent iwithout ireceiving ian iacknowledgment.

• Sender iWindow: iThe isender ican isend imultiple ipackets iwithin ithe
iwindow isize iwithout iwaiting ifor ian iacknowledgment ifor ieach ipacket.

• Receiver iWindow: iThe ireceiver ican ireceive imultiple ipackets iand imay
isend icumulative iacknowledgments, iindicating ithe ihighest isequence

inumber ireceived icorrectly.

Types iof iSliding iWindow iProtocols

1. iStop-and-Wait iProtocol

Overview:
 • Simplest iform iof isliding iwindow iprotocol.
• The isender isends ione ipacket iand iwaits ifor ian iacknowledgment ibefore
isending ithe inext ipacket.

• Window isize iis ieffectively i1 i(only ione ipacket ican ibe ioutstanding iat ia
itime).

Advantages:

• Simple ito iimplement.

• Easier ierror iand iflow icontrol.

Disadvantages:

• Inefficient iuse iof iresources, iespecially iover ihigh-latency ior ihigh-

bandwidth inetworks.
• Poor iutilization iof iavailable ibandwidth idue ito iwaiting ifor
iacknowledgment iafter ieach ipacket.

Process:

1. Send iPacket: iThe isender isends ia isingle ipacket.

2. Wait ifor iACK: iThe isender iwaits ifor ian iacknowledgment ifrom ithe
ireceiver.

3. ACK iReceived: iUpon ireceiving ithe iacknowledgment, ithe isender isends

ithe inext ipacket.

4. Timeout: iIf ian iacknowledgment iis inot ireceived iwithin ia icertain iperiod,
ithe isender iretransmits ithe ipacket.

Example i: i

Sender: i iP1 i iwait i iACK1

Receiver: i i i i iP1 i-> i isend iACK1

2. iGo-Back-N iProtocol

Overview:

• More iadvanced ithan iStop-and-Wait.

• Allows ithe isender ito isend imultiple ipackets ibefore ineeding ian
iacknowledgment, iup ito ia ispecified iwindow isize i(N).
 • If ia ipacket iis ilost ior ian ierror iis idetected, iall isubsequent ipackets iin ithe
iwindow iare iretransmitted.

Advantages:

• Better iutilization iof inetwork ibandwidth icompared ito iStop-and-Wait.

• More iefficient ierror irecovery ithan iStop-and-Wait.

Disadvantages:

• May ilead ito iredundant iretransmissions iif ian ierror ioccurs, ias iall
isubsequent ipackets iare iretransmitted.

• Requires imore icomplex ilogic ito imanage ithe isending iand

iacknowledgment iprocess.

Process:

1. Send iPackets: iThe isender isends ipackets iup ito ithe iwindow isize iN.
2. Wait ifor iACKs: iThe isender iwaits ifor iacknowledgments ibut ican icontinue
isending inew ipackets iwithin ithe iwindow isize.

3. ACK iReceived: iThe isender islides ithe iwindow iforward ibased ion ithe
iacknowledgments ireceived.

4. Timeout ior iNAK: iIf ia ipacket iacknowledgment iis inot ireceived iwithin ia
icertain iperiod, ithe isender igoes iback ito ithe isequence inumber iof ithe ilost

ipacket iand iretransmits iall isubsequent ipackets.

Example:

Sender: i iP1 iP2 iP3 iP4 iP5 i iwait iACK

Receiver: i i i iP1 iP2 iP3 i(lost iP4) i iNAK4 i i-> isend iACK2

Sender: i iP4 iP5

Receiver: i i i iP4 iP5 i-> isend iACK5

Comparison iof iStop-and-Wait iand iGo-Back-N

 Feature Stop-and-Wait Go-Back-N
Window iSize i i i i i i i i i i i i i i i i i i i1 i i i i i i i i i i i i i i i i i i i iN i(greater ithan i1)

Efficiency i i i i i i i i i i i i i iLow, idue ito iwaiting

i i i i i iHigher, ias imultiple ipackets iare isent
iiii ifor i i i i ieach iACK

Limited iby iround-trip itime i i i i i iHigher ithroughput iwith ibetter

Throughput
i(RTT) iutilization i i i iof ibandwidth

iSimple, iretransmit isingle i i i i i i iMore icomplex, iretransmit ifrom ierror

Error iHandling
i i i i i i i i i i i i i i ipacket ipoint

iMinimal ibuffer i i i i i i
Resource iUsage i i i i iRequires ilarger ibuffer isizes
irequirements

i i i i i iMore icomplex idue ito itracking

Implementation i i i iSimple
imultiple ipackets iand iacknowledgments

[Link] i3 iExplain ithe istructure iof ian iIPv4 iaddress iin idetail. iAlso idiscuss ithe
iimportance iand ipurpose iof iInternet iaddress iclasses i i?

ANS i iStructure iof ian iIPv4 iAddress

An iIPv4 iaddress iis ia i32-bit inumeric iaddress ithat iuniquely iidentifies ia idevice ion
ian iIP inetwork. iThe iaddress iis idivided iinto ifour i8-bit ioctets, ieach iranging ifrom

i0 ito i255, iand iis itypically iwritten iin idecimal iformat, iseparated iby idots i(e.g.,

i192.168.0.1).

Binary iand iDecimal iRepresentation

Each ioctet ican ibe irepresented iin ibinary i(base i2) ior idecimal i(base i10) inotation.
iFor iexample:

Binary: i i11000000.10101000.00000000.00000001
Decimal: i192 i i i i i i.168 i i i i i i.0 i i i i i i i.1

Network iand iHost iPortions

An iIPv4 iaddress iconsists iof itwo imain iparts:

 • Network iPortion: iIdentifies ithe ispecific inetwork ion iwhich ia idevice
iresides.

• Host iPortion: iIdentifies ithe ispecific idevice i(or ihost) iwithin ithat inetwork.

The idivision ibetween ithe inetwork iand ihost iportions iis idetermined iby ithe
isubnet imask, iwhich ialso iconsists iof i32 ibits. iThe isubnet imask iuses icontiguous

ibits iset ito i1 i(for ithe inetwork iportion) ifollowed iby ibits iset ito i0 i(for ithe ihost

iportion).

For iexample, iwith ian iaddress i192.168.1.10 iand ia isubnet imask i255.255.255.0:

Address: i i i i i i192.168.1.10

Subnet iMask: i i255.255.255.0 i(11111111.11111111.11111111.00000000)

Network: i i i i i i192.168.1.0

Host: i i i i i i i i i10

Internet iAddress iClasses

IPv4 iaddresses iare icategorized iinto ifive imain iclasses i(A, iB, iC, iD, iand iE) ibased
ion ithe ifirst ifew ibits iof ithe iaddress. iThis iclassification ihelps iin iorganizing ithe

iaddress ispace iefficiently.

Class iA

• First iBit: i0
• Range: i1.0.0.0 ito i126.0.0.0
• Default iSubnet iMask: i255.0.0.0
• Network/Host: i8 ibits inetwork, i24 ibits ihost
• Usage: iLarge inetworks iwith imany ihosts i(e.g., ilarge ienterprises, iISPs).

Class iB

• First iBits: i10

• Range: i128.0.0.0 ito i191.255.0.0
• Default iSubnet iMask: i255.255.0.0
• Network/Host: i16 ibits inetwork, i16 ibits ihost
• Usage: iMedium-sized inetworks i(e.g., iuniversities, ismall iISPs).

Class iC
 • First iBits: i110
• Range: i192.0.0.0 ito i223.255.255.0
• Default iSubnet iMask: i255.255.255.0
• Network/Host: i24 ibits inetwork, i8 ibits ihost
• Usage: iSmall inetworks i(e.g., ismall ibusinesses, iprivate inetworks).

Class iD

• First iBits: i1110

• Range: i224.0.0.0 ito i239.255.255.255
• Usage: iMulticast iaddresses i(for igroup icommunication).

Class iE

• First iBits: i1111

• Range: i240.0.0.0 ito i255.255.255.255
• Usage: iReserved ifor ifuture iuse, iresearch, iand idevelopment.

Importance iand iPurpose iof iInternet iAddress iClasses

Efficient iAllocation

Address iclasses ienable iefficient iallocation iof iIP iaddresses ibased ion ithe isize iof
ithe inetwork. iLarge iorganizations ireceive iClass iA iaddresses, imedium-sized

iorganizations ireceive iClass iB iaddresses, iand ismall iorganizations ireceive iClass iC

iaddresses. iThis iprevents ithe iwastage iof iIP iaddresses iand iensures ithat

idifferent inetwork isizes iare icatered ito iappropriately.

Simplified iRouting

Class-based iaddressing isimplifies irouting iby iallowing irouters ito ihandle ipackets
ibased ion ithe inetwork iportion iof ithe iaddress. iThis iaggregation ireduces ithe

inumber iof irouting itable ientries iand ienhances ithe ispeed iand iefficiency iof

irouting idecisions.

Hierarchical iStructure

The ihierarchical istructure iof iIP iaddress iclasses isupports ithe idelegation iof
iaddress ispaces ito idifferent iorganizations, ienabling ia iscalable iand imanageable

iglobal iIP iaddress isystem.

Transition ito iCIDR

While iclassful iaddressing iprovided ian iinitial istructure, iit iled ito iinefficiencies
iand iaddress ispace iexhaustion. iClassless iInter-Domain iRouting i(CIDR) iwas

iintroduced ito iovercome ithese ilimitations. iCIDR ireplaces ithe ifixed-length

isubnet imask iwith ivariable-length isubnet imasking, iallowing imore iflexible iand

iefficient iallocation iof iIP iaddresses. iIt ialso isupports iaggregation, ireducing ithe

isize iof irouting itables.

Conclusion

Understanding ithe istructure iof ian iIPv4 iaddress iand ithe ipurpose iof iaddress
iclasses iis ifundamental ito inetworking. iThis iknowledge ihelps iin inetwork idesign,

iefficient iIP iaddress imanagement, iand ioptimized irouting. iDespite ithe itransition

ito imore iflexible imethods ilike iCIDR, ithe ibasic iconcepts iof iIPv4 iaddressing iand

iclasses iremain icritical iin iunderstanding iIP inetworks.

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii SET-2

[Link] i4 iDefine iCongestion iin iNetworking iand iexplain ithe ireasons ibehind ithe
ioccurrence iof iCongestion. iExplain ithe iconcept iof itraffic ishaping iand ithe irole iof

ithe ileaky ibucket ialgorithm iin imanaging inetwork itraffic. i

ANS i i

Congestion iin inetworking irefers ito ia istate iwhere ithe idemand ifor inetwork
iresources iexceeds ithe iavailable icapacity, ileading ito ia idegradation iin inetwork

iperformance. iThis itypically imanifests ias iincreased ilatency, ipacket iloss, iand

ireduced ithroughput, imaking iit idifficult ifor idata ito ibe itransmitted iefficiently

iacross ithe inetwork.

Reasons iBehind ithe iOccurrence iof iCongestion

1. High iTraffic iLoad:

o When ia ilarge inumber iof ipackets iare isent ito ithe inetwork
isimultaneously, iit ican ioverwhelm ithe inetwork iresources, isuch ias

ibandwidth iand ibuffers, icausing icongestion.

2. Insufficient iBandwidth:
 o If ithe inetwork ibandwidth iis iinsufficient ito ihandle ithe ivolume iof
itraffic, icongestion ican ioccur. iThis ioften ihappens iin inetworks iwith

ilimited icapacity ior iwhen ia isudden isurge iin itraffic ioccurs.

3. Network iBottlenecks:
o Certain ipoints iin ithe inetwork imay ibecome ibottlenecks, iwhere ithe
idata iflow iis iconstrained idue ito ilimited iprocessing ipower ior

ibandwidth, icausing icongestion.

4. Poor iNetwork iDesign:

o Inefficient inetwork idesign, isuch ias ihaving itoo ifew ipaths ifor idata
ito itravel ior ipoorly iconfigured irouters iand iswitches, ican ilead ito

icongestion.

5. Traffic iBursts:
o Sudden ispikes iin itraffic, ioften idue ito ispecific ievents ior
iapplications, ican itemporarily ioverload ithe inetwork, ileading ito

icongestion.

6. Lack iof iQuality iof iService i(QoS):

o Without iQoS imechanisms ito iprioritize icritical itraffic, inetworks ican
ibecome icongested iwith ilower-priority idata, iaffecting ithe

iperformance iof iimportant iapplications.

7. Inefficient iProtocols:
o Protocols ithat ido inot ihandle icongestion iwell, ior iare ipoorly
iconfigured, ican iexacerbate icongestion iproblems.

Traffic iShaping

Traffic iShaping iis ia itechnique iused ito icontrol ithe iflow iand ivolume iof inetwork
itraffic ito iensure iefficient iuse iof ibandwidth iand ito iprevent icongestion. iBy

iregulating ithe irate iat iwhich idata ipackets iare isent iinto ithe inetwork, itraffic

ishaping ihelps ito imaintain ia isteady iflow iof itraffic, iavoiding isudden ibursts ithat

ican ilead ito icongestion.

Key iConcepts iof iTraffic iShaping

1. Rate iLimiting:
o Controlling ithe irate iat iwhich ipackets iare isent ito iensure ithat
itraffic iconforms ito ia ispecified ibandwidth.

2. Burst iControl:
o Allowing ifor ioccasional ibursts iof itraffic iwhile iensuring ithat ithe
ioverall irate idoes inot iexceed ithe ipredetermined ilimit.

3. Smoothing iTraffic:
 o Distributing itraffic ievenly iover itime ito iavoid ipeaks ithat ican icause
icongestion.

Leaky iBucket iAlgorithm

The iLeaky iBucket iAlgorithm iis ia itraffic ishaping imechanism iused ito icontrol ithe
irate iat iwhich ipackets iare isent iinto ithe inetwork. iIt iensures ithat idata

itransmission iis ismooth iand iconforms ito ithe ispecified irate, ipreventing

icongestion.

How ithe iLeaky iBucket iAlgorithm iWorks

1. Leaky iBucket ias ia iMeter:

o Imagine ia ibucket iwith ia ismall ihole iat ithe ibottom. iWater
i(representing idata ipackets) iis iadded ito ithe ibucket iat ivarying

irates. iThe iwater ileaks iout iof ithe ihole iat ia iconstant irate,

iregardless iof ihow iquickly iwater iis iadded ito ithe ibucket.

2. Bucket iOverflow:
o If iwater i(data) iis iadded itoo iquickly iand iexceeds ithe ibucket's
icapacity, ithe iexcess iwater iis idiscarded, isimilar ito ihow ipackets iare

idropped iwhen ithe ibuffer ioverflows iin ia inetwork idevice.

3. Constant iOutput iRate:

o The ialgorithm iensures ithat ipackets ileave ithe ibucket i(are
itransmitted) iat ia iconstant irate, ismoothing iout iany ibursts iin

iincoming itraffic.

Role iof ithe iLeaky iBucket iAlgorithm iin iManaging iNetwork iTraffic

• Rate iControl:
o By iensuring ia iconstant ioutput irate, ithe ileaky ibucket ialgorithm
iprevents isudden ibursts iof itraffic ifrom ioverwhelming ithe inetwork,

ithus ireducing ithe ichances iof icongestion.

• Traffic iSmoothing:
o The ialgorithm ismooths iout iirregular itraffic ipatterns, iproviding ia
isteady iflow iof ipackets ito ithe inetwork, iwhich ihelps iin imaintaining

ioverall inetwork iperformance.

• Buffer iManagement:
o The ileaky ibucket iacts ias ia ibuffer, itemporarily istoring iincoming
ipackets iand icontrolling itheir irelease iinto ithe inetwork. iThis ihelps

iin imanaging ithe itraffic iload iand iavoiding icongestion.

[Link] i5 iWrite ishort inote ion: iMIME, iPOP, iSMTP i? i

ANS i iMIME i(Multipurpose iInternet iMail iExtensions)

MIME iis ia istandard ithat iextends ithe iformat iof iemail ito isupport:

• Text iin icharacter isets iother ithan iASCII.

• Non-text iattachments, isuch ias iimages, iaudio, ivideo, iand iapplication
ifiles.

• Message ibodies iwith imultiple iparts.

• Header iinformation iin inon-ASCII icharacter isets.

Key iFeatures:

• Content-Type iHeader: iSpecifies ithe imedia itype iof ithe icontent. iFor
iexample, itext/plain, itext/html, iimage/jpeg.

• Content-Transfer-Encoding iHeader: iSpecifies ithe iencoding iused ito isafely

itransfer ithe ibody iover ithe itransport imechanism. iCommon iencodings

iinclude ibase64, iquoted-printable, iand ibinary.

• Multipart iMessages: iMIME iallows iemails ito icontain imultiple iparts, ieach
iwith iits iown icontent itype iand iencoding. iThis ienables ithe iinclusion iof

iattachments iand icomplex imessage istructures.

Example: i

MIME-Version: i1.0

Content-Type: imultipart/mixed; iboundary="boundary"

--boundary

Content-Type: itext/plain; icharset="UTF-8"

This iis ithe ibody iof ithe iemail.

--boundary
Content-Type: iimage/jpeg

Content-Transfer-Encoding: ibase64

<base64 iencoded iimage>

--boundary—

POP i(Post iOffice iProtocol)

POP iis ian iemail iprotocol iused iby ilocal iemail iclients ito iretrieve imessages ifrom
ia iremote iserver iover ia iTCP/IP iconnection. iThe icurrent iversion iis iPOP3.

Key iFeatures:

• Download iand iDelete: iBy idefault, iPOP idownloads iemail imessages ifrom
ithe iserver ito ithe iclient iand ithen ideletes ithem ifrom ithe iserver. iThis iis

isuitable ifor iaccessing imail ifrom ia isingle idevice.

• Optional iLeave ion iServer: iSome iclients iallow imessages ito ibe ileft ion ithe
iserver iafter idownloading, ienabling iaccess ifrom imultiple idevices.

• Simple iProtocol: iPOP iis istraightforward iand ieasy ito iimplement, imaking
iit iwidely iused iin iemail isystems.

Workflow:

1. Connect ito iServer: iThe iclient iconnects ito ithe imail iserver.
2. Authenticate: iThe iuser iprovides ia iusername iand ipassword.
3. Retrieve iMessages: iThe iclient idownloads ithe imessages ifrom ithe iserver.
4. Delete iMessages i(Optional): iThe iclient imay idelete ithe imessages ifrom
ithe iserver iafter idownloading.

5. Disconnect: iThe iclient icloses ithe iconnection ito ithe iserver.

SMTP i(Simple iMail iTransfer iProtocol)

SMTP iis ia iprotocol ifor isending iemail imessages ibetween iservers. iIt iis iused iby
iemail iclients ito isend imessages ito ia imail iserver iand iby imail iservers ito irelay

imessages ito itheir idestination.

Key iFeatures:
 • Push iProtocol: iSMTP iis ia ipush iprotocol, imeaning iit iis iused ito ipush iemail
imessages ifrom ithe iclient ito ithe iserver iand ibetween iservers.

• Command iand iResponse: iSMTP ioperates ithrough ia iseries iof icommand

iand iresponse iexchanges ibetween ithe iclient iand iserver.

• Supports iMIME: iSMTP isupports iMIME ito ihandle iemails iwith idifferent
icontent itypes iand iattachments.

Workflow:

1. Establish iConnection: iThe iclient iestablishes ia iconnection ito ithe iSMTP

iserver, itypically ion iport i25 i(unencrypted) ior iport i587/465 i(encrypted).

2. Send iCommands: iThe iclient isends ia iseries iof icommands ito ithe iserver,
iincluding:

o HELO ior iEHLO: iInitiate ithe iconversation.

o MAIL iFROM: iSpecify ithe isender's iemail iaddress.
o RCPT iTO: iSpecify ithe irecipient's iemail iaddress.
o DATA: iIndicate ithe istart iof ithe imessage icontent.
3. Transfer iMessage: iThe iclient isends ithe iemail imessage, iincluding iheaders
iand ibody.

4. End iTransmission: iThe iclient isignals ithe iend iof ithe imessage iwith ia isingle
iperiod i(.) ion ia iline iby iitself.

5. Close iConnection: iThe iclient icloses ithe iconnection iafter ireceiving

iconfirmation ifrom ithe iserver.

Example:

HELO [Link]

250 iHello [Link]

MAIL iFROM:<sender@[Link]>

250 iOK

RCPT iTO:<recipient@[Link]>

250 iOK
DATA

354 iStart imail iinput; iend iwith i<CRLF>.<CRLF>

Subject: iTest iEmail

This iis ia itest iemail.

250 iOK: iqueued ias i12345

QUIT

221 iBye

[Link] i6 iExplain ithe irole iand isignificance iof ithe iDomain iName iSystem i(DNS) iin
icomputer inetworking. iAlso idifferentiate ibetween istatic iand idynamic iweb

ipages i?

ANS i iThe iRole iand iSignificance iof ithe iDomain iName iSystem i(DNS) iin iComputer
iNetworking

Domain iName iSystem i(DNS) iis ia ihierarchical iand idecentralized inaming isystem
iused ito iresolve ihuman-readable idomain inames i(e.g., [Link]) iinto

iIP iaddresses i(e.g., i192.0.2.1) ithat icomputers iuse ito iidentify ieach iother ion ithe

inetwork. iDNS iis iessential ifor ithe ifunctionality iof ithe iinternet ias iit ienables

iusers ito iaccess iwebsites iusing ieasy-to-remember idomain inames iinstead iof

icomplex inumerical iIP iaddresses.

Key iFunctions iof iDNS:

1. Name iResolution:
 o Converts idomain inames iinto iIP iaddresses, ienabling ithe irouting iof
idata ito ithe icorrect idestination.

2. Hierarchical iStructure:
o Organizes idomain inames iin ia ihierarchical imanner, istarting ifrom
ithe iroot idomain, ifollowed iby itop-level idomains i(TLDs), isecond-

level idomains, iand iso ion.

3. Decentralization:
o Distributes ithe iresponsibility iof idomain iname imanagement iacross
ivarious ientities, ipreventing ibottlenecks iand isingle ipoints iof

ifailure.

4. Load iDistribution:
o Balances ithe iload iby idistributing iDNS iqueries iacross imultiple
iservers, iensuring iefficient ihandling iof irequests iand iimproved

iperformance.

5. Caching:
o DNS iservers icache iquery iresults ito ispeed iup isubsequent irequests
ifor ithe isame idomain, ireducing ilatency iand iimproving iuser

iexperience.

How iDNS iWorks:

1. DNS iQuery:
o A iuser itypes ia idomain iname iinto ia iweb ibrowser. iThe ibrowser
isends ia iDNS iquery ito ia iDNS iresolver i(often iprovided iby ithe iuser's

iISP).

2. Recursive iQuery:
o The iDNS iresolver iperforms ia irecursive iquery, icontacting imultiple
iDNS iservers i(root, iTLD, iauthoritative) iuntil iit ifinds ithe iIP iaddress

icorresponding ito ithe idomain iname.

3. Response:
o The iDNS iresolver ireturns ithe iIP iaddress ito ithe ibrowser, iwhich ican
ithen iestablish ia iconnection ito ithe iweb iserver ihosting ithe

iwebsite.

4. Caching:
o The iresolver iand ithe ibrowser icache ithe iDNS iresponse ito ispeed iup
ifuture irequests ifor ithe isame idomain.

Static ivs. iDynamic iWeb iPages

Static iWeb iPages

Static iWeb iPages iare iweb ipages ithat iare ifixed iand ido inot ichange iin iresponse
ito iuser iinteractions. iThey iare icreated iusing iHTML iand idisplay ithe isame

icontent ito ievery ivisitor.

Characteristics:

• Content: iPre-defined iand idoes inot ichange iunless imanually iupdated iby ia
iweb ideveloper.

• Technology: iTypically ibuilt iusing iHTML, iCSS, iand isometimes iJavaScript

ifor isimple iinteractivity.

• Server-Side iProcessing: iNo iserver-side iprocessing; ithe iweb iserver isimply

iserves ithe iHTML ifile ito ithe ibrowser.

• Performance: iGenerally ifaster ito iload isince ino iserver-side iprocessing iis
irequired.

• Use iCases: iSuitable ifor isimple iwebsites ilike iportfolios, iblogs, ior
iinformational ipages iwhere icontent iis iinfrequently iupdated.

Example:

<!DOCTYPE ihtml>

<html>

<head>

iiii <title>Static iPage iExample</title>

</head>

<body>

iiii <h1>Welcome ito iMy iStatic iWebsite</h1>

iiii <p>This icontent idoes inot ichange.</p>

</body>

</html>

Dynamic iWeb iPages

Dynamic iWeb iPages iare iweb ipages ithat ican ichange itheir icontent ibased ion
iuser iinteractions ior iother ifactors. iThey iare igenerated iin ireal-time iby iserver-

side iscripts.

Characteristics:

• Content: iGenerated idynamically, ioften ibased ion iuser iinput, idatabase

iqueries, ior iother iserver-side ilogic.

• Technology: iBuilt iusing iserver-side iscripting ilanguages isuch ias iPHP,

[Link], iJava, iPython, ior [Link], iin icombination iwith iHTML, iCSS, iand

iJavaScript.

• Server-Side iProcessing: iRequires iserver-side iprocessing ito igenerate ithe

icontent ibefore isending iit ito ithe ibrowser.

• Performance: iCan ibe islower ito iload idue ito ithe iprocessing irequired ito
igenerate ithe ipage, ibut icaching iand ioptimization itechniques ican

imitigate ithis.

• Use iCases: iSuitable ifor iinteractive iwebsites ilike ie-commerce isites, isocial
inetworks, icontent imanagement isystems i(CMS), iand iweb iapplications

iwhere icontent iis ifrequently iupdated ior ipersonalized.

Example i(PHP):

<!DOCTYPE ihtml>

<html>

<head>

iiii <title>Dynamic iPage iExample</title>

</head>

<body>

iiii <h1>Welcome ito iMy iDynamic iWebsite</h1>

iiii <p>Today's idate iand itime iis: i<?php iecho idate('Y-m-d iH:i:s'); i?></p>

</body>

</html>
The iDomain iName iSystem i(DNS) iplays ia icritical irole iin icomputer inetworking iby
itranslating ihuman-readable idomain inames iinto iIP iaddresses, ienabling

iseamless iaccess ito iwebsites iand iother iinternet iresources. iStatic iweb ipages

ioffer ifixed icontent isuitable ifor isimple iand iinfrequently iupdated iwebsites, iwhile

idynamic iweb ipages iprovide iinteractive iand ipersonalized icontent, iideal ifor

icomplex iand ifrequently iupdated iweb iapplications. iBoth itypes iof iweb ipages

iserve idifferent ipurposes iand iare ichosen ibased ion ithe irequirements iof ithe

iwebsite ior iapplication.