CSCI 6760 - Computer Networks Spring 2017
source: computer-networks-webdesign.comCSCI 6760 - Computer NetworksSpring 2017Instructor: Prof. Roberto Perdisciperdisci@cs.uga.eduThese slides are adapted from the textbook slides by J.F. Kurose and K.W. Ross
Chapter 3: Transport LayerOur goals:} understand principlesbehind transport liable data transferflow controlcongestion control}learn about transport layerprotocols in the Internet:}}}UDP: connectionless transportTCP: connection-orientedtransportTCP congestion controlTransport Layer
Transport services and protocols}}}provide logical communicationbetween app processes running ondifferent hoststransport protocols run in endsystems} send side: breaks long appmessages into segments, passesto network layer} rcv side: reassembles segmentsinto messages, passes to applayermore than one transport protocolavailable to apps} Internet: TCP and UDP3-3applicationtransportnetworkdata linkphysicalapplicationtransportnetworkdata linkphysicalTransport Layer
Transport vs. network layer}}network layer: logicalcommunication betweenhoststransport layer: logicalcommunication betweenprocesses}3-4relies on and enhances networklayer servicesHousehold analogy:12 kids sending letters to 12kids} processes kids} app messages letters inenvelopes} hosts houses} transport protocol Annand Bill} network-layer protocol postal serviceTransport Layer
Internet transport-layer protocols}reliable, in-order delivery(TCP)}}}}networkdata linkphysicalextension of “best-effort” IPnetworkdata linkphysicalDo not provide:}}3-5networkdata linkphysicalnetworkdata linkphysicalnetworkunreliable, unordereddelivery: UDP}}connection setupflow controlcongestion controlapplicationtransportnetworkdata linkphysicaldelay guaranteesbandwidth guaranteesTransport Layerdata linkphysicalnetworkdata linkphysicalapplicationtransportnetworkdata linkphysical
Multiplexing/demultiplexingMultiplexing at send host:gathering data from multiplesockets, enveloping data withheader (later used 1P1delivering received segmentsto correct socket socketapplicationP2transportnetwork alhost 13-6P3Demultiplexing at rcv host:physicalhost 2Transport Layerphysicalhost 3
How demultiplexing works}}host receives IP datagrams} each datagram has source IPaddress, destination IP address} each datagram carries 1transport-layer segment} each segment has source anddestination port numberhost uses IP addresses & portnumbers to direct segment toappropriate socket32 bitssource port #dest port #other header fieldsapplicationdata(message)TCP/UDP segment format3-7Transport Layer
Connectionless demultiplexing}Create sockets with portnumbers:}}DatagramSocket mySocket1 newDatagramSocket(12534);DatagramSocket mySocket2 newDatagramSocket(12535);}UDP socket identified by twotuple:(dest IP address, dest port number)3-8When host receives UDPsegment:}}checks destination port numberin segmentdirects UDP segment to socketwith that port numberIP datagrams with differentsource IP addresses and/orsource port numbersdirected to same socketTransport Layer
Connectionless demux (cont)DatagramSocket serverSocket new DatagramSocket(6428);P2SP: 6428DP: 9157clientIP: AP1P1P3SP: 9157DP: 6428SP: 6428DP: 5775serverIP: CSP: 5775DP: 6428IP:BSP provides “return address”3-9ClientTransport Layer
Connection-oriented demux}TCP socket identified by 4tuple:}}}}}source IP addresssource port numberdest IP addressdest port numberreceiving host uses all fourvalues to direct segment toappropriate socket3-10}Server host may supportmany simultaneous TCPsockets:}}each socket identified by its own4-tupleWeb servers have differentsockets for each connectingclient}non-persistent HTTP will havedifferent socket for each requestTransport Layer
Connection-oriented demux (cont)P1P4P5P2P6P1P3SP: 5775DP: 80S-IP: BD-IP:CclientIP: A3-11SP: 9157DP: 80S-IP: AD-IP:CSP: 9157DP: 80serverIP: CS-IP: BD-IP:CTransport LayerClientIP:B
Connection-oriented demux:Threaded Web ServerP1P2P4P1P3SP: 5775DP: 80S-IP: BD-IP:CclientIP: A3-12SP: 9157DP: 80S-IP: AD-IP:CSP: 9157DP: 80serverIP: CS-IP: BD-IP:CTransport LayerClientIP:B
Chapter 3 outline}}}}3.1 Transport-layer services3.2 Multiplexing anddemultiplexing3.3 Connectionlesstransport: UDP3.4 Principles of reliable datatransfer}}}}}}}3-133.5 Connection-orientedtransport: TCPsegment structurereliable data transferflow controlconnection management3.6 Principles of congestioncontrol3.7 TCP congestion controlTransport Layer
UDP: User Datagram Protocol[RFC768]}}}“no frills,” “bare bones” Internettransport protocol“best effort” service, UDPsegments may be:} lost} delivered out of order to appconnectionless:} no handshaking betweenUDP sender, receiver} each UDP segment handledindependently of others3-14Why is there a UDP?}}}}no connection establishment(which can add delay)simple: no connection state atsender, receiversmall segment headerno congestion control: UDP canblast away as fast as desiredTransport Layer
UDP: more}}often used for streamingmultimedia apps} loss tolerant} rate sensitiveother UDP usesLength, inbytes of UDPsegment,includingheaderDNS} SNMPreliable transfer over UDP: addreliability at application layer} application-specific errorrecovery!}}32 bitssource port #dest port #lengthchecksumApplicationdata(message)UDP segment format3-15Transport Layer
UDP checksumGoal: detect “errors” (e.g., flipped bits) in transmittedsegmentSender:}}}treat segment contents assequence of 16-bit integerschecksum: addition (1’scomplement sum) of segmentcontentssender puts checksum valueinto UDP checksum field3-16Receiver:}}compute checksum of receivedsegmentcheck if computed checksumequals checksum field value:} NO - error detected} YES - no error detected. Butmaybe errors nonetheless? Morelater .Transport Layer
Internet Checksum Example}Note} When adding numbers, a carryout from the most significantbit needs to be added to the result}Example: add two 16-bit integers1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 13-17Transport Layer
Principles of Reliable data transfer}}}important in app., transport, link layerstop-10 list of important networking topics!characteristics of unreliable channel will determine complexity ofreliable data transfer protocol (rdt)3-18Transport Layer
Principles of Reliable data transfer3-19Transport Layer
Principles of Reliable data transfer3-20Transport Layer
Reliable data transfer: getting startedrdt send(): called from above,(e.g., by app.). Passed data todeliver to receiver upper layerdeliver data(): called byrdt to deliver data to uppersendsideudt send(): called by rdt,to transfer packet overunreliable channel to receiver3-21receivesiderdt rcv(): called when packetarrives on rcv-side of channelTransport Layer
Reliable data transfer: getting startedWe’ll:} incrementally develop sender, receiver sides of reliabledata transfer protocol (rdt)} consider only unidirectional data transfer}}but control info will flow on both directions!use finite state machines (FSM) to specify sender,receiverevent causing state transitionactions taken on state transitionstate: when in this“state” next stateuniquely determinedby next event3-22state1eventactionsTransport Layerstate2
Rdt1.0:}underlying channel perfectly reliable}}}reliable transfer over a reliable channelno bit errorsno loss of packetsseparate FSMs for sender, receiver:}}sender sends data into underlying channelreceiver read data from underlying channelWait forcall fromaboverdt send(data)packet make pkt(data)udt send(packet)sender3-23rdt rcv(packet)extract (packet,data)deliver data(data)Wait forcall frombelowreceiverTransport Layer
Rdt2.0: channel with bit errors}underlying channel may flip bits in packet}}the question: how to recover from errors:}}}}acknowledgements (ACKs): receiver explicitly tells sender that pktreceived OKnegative acknowledgements (NAKs): receiver explicitly tells sender thatpkt had errorssender retransmits pkt on receipt of NAKnew mechanisms in rdt2.0 (beyond rdt1.0):}}3-24checksum to detect bit errorserror detectionreceiver feedback: control msgs (ACK,NAK) rcvr- senderTransport Layer
rdt2.0: FSM specificationrdt send(data)sndpkt make pkt(data, checksum)udt send(sndpkt)rdt rcv(rcvpkt) &&isNAK(rcvpkt)Wait forWait forcall fromACK orudt send(sndpkt)aboveNAKrdt rcv(rcvpkt) && isACK(rcvpkt)Λreceiverrdt rcv(rcvpkt) &&corrupt(rcvpkt)udt send(NAK)Wait forcall frombelowsenderrdt rcv(rcvpkt) &¬corrupt(rcvpkt)extract(rcvpkt,data)deliver data(data)udt send(ACK)3-25Transport Layer
rdt2.0: operation with no errorsrdt send(data)snkpkt make pkt(data, checksum)udt send(sndpkt)rdt rcv(rcvpkt) &&isNAK(rcvpkt)Wait forWait forcall fromACK orudt send(sndpkt)aboveNAKrdt rcv(rcvpkt) && isACK(rcvpkt)rdt rcv(rcvpkt) &&corrupt(rcvpkt)udt send(NAK)Wait forcall frombelowΛrdt rcv(rcvpkt) &¬corrupt(rcvpkt)extract(rcvpkt,data)deliver data(data)udt send(ACK)3-26Transport Layer
rdt2.0: error scenariordt send(data)snkpkt make pkt(data, checksum)udt send(sndpkt)rdt rcv(rcvpkt) &&isNAK(rcvpkt)Wait forWait forcall fromACK orudt send(sndpkt)aboveNAKrdt rcv(rcvpkt) && isACK(rcvpkt)rdt rcv(rcvpkt) &&corrupt(rcvpkt)udt send(NAK)Wait forcall frombelowΛrdt rcv(rcvpkt) &¬corrupt(rcvpkt)extract(rcvpkt,data)deliver data(data)udt send(ACK)3-27Transport Layer
rdt2.0 has a fatal flaw!What happens if ACK/NAKcorrupted?}}sender doesn’t know whathappened at receiver!can’t just retransmit: possibleduplicateHandling duplicates:}}}sender retransmits current pktif ACK/NAK garbledsender adds sequence number toeach pktreceiver discards (doesn’tdeliver up) duplicate pktstop and waitSender sends one packet,then waits for receiverresponse3-28Transport Layer
rdt2.1: handles garbled ACK/NAKssenderrdt send(data)sndpkt make pkt(0, data, checksum)udt send(sndpkt)rdt rcv(rcvpkt) &&Wait forcall 0 fromaboverdt rcv(rcvpkt)&& notcorrupt(rcvpkt)&& isACK(rcvpkt)( corrupt(rcvpkt) isNAK(rcvpkt) )udt send(sndpkt)Wait forACK orNAK 0rdt rcv(rcvpkt)&& notcorrupt(rcvpkt)&& isACK(rcvpkt)Λrdt rcv(rcvpkt) &&( corrupt(rcvpkt) isNAK(rcvpkt) )udt send(sndpkt)3-29ΛWait forACK orNAK 1Wait forcall 1 fromaboverdt send(data)sndpkt make pkt(1, data, checksum)udt send(sndpkt)Transport Layer
rdt2.1: handles garbled ACK/NAKsreceiverrdt rcv(rcvpkt) && corrupt(rcvpkt)rdt rcv(rcvpkt) && notcorrupt(rcvpkt)&& has seq0(rcvpkt)extract(rcvpkt,data)deliver data(data)sndpkt make pkt(ACK, chksum)udt send(sndpkt)rdt rcv(rcvpkt) && corrupt(rcvpkt)sndpkt make pkt(NAK, chksum)udt send(sndpkt)rdt rcv(rcvpkt) &¬ corrupt(rcvpkt) &&has seq1(rcvpkt)sndpkt make pkt(ACK, chksum)udt send(sndpkt)sndpkt make pkt(NAK, chksum)udt send(sndpkt)Wait for0 frombelowWait for1 frombelowrdt rcv(rcvpkt) && notcorrupt(rcvpkt)&& has seq1(rcvpkt)rdt rcv(rcvpkt) &¬ corrupt(rcvpkt) &&has seq0(rcvpkt)sndpkt make pkt(ACK, chksum)udt send(sndpkt)extract(rcvpkt,data)deliver data(data)sndpkt make pkt(ACK, chksum)udt send(sndpkt)3-30Transport Layer
rdt2.1: discussionSender:} seq # added to pkt} two seq. #’s (0,1) will suffice.Why?} must check if received ACK/NAK corrupted} twice as many states}3-31state must “remember”whether “current” pkt has 0 or1 seq. #Receiver:} must check if receivedpacket is duplicate}}state indicates whether 0 or 1is expected pkt seq #note: receiver can not knowif its last ACK/NAK receivedOK at senderTransport Layer
rdt2.2: a NAK-free protocol}}same functionality as rdt2.1, using ACKs onlyinstead of NAK, receiver sends ACK for last pkt received OK}}receiver must explicitly include seq # of pkt being ACKedduplicate ACK at sender results in same action as NAK:retransmit current pkt3-32Transport Layer
rdt2.2: sender, receiver fragmentsrdt send(data)sndpkt make pkt(0, data, checksum)udt send(sndpkt)rdt rcv(rcvpkt) &&( corrupt(rcvpkt) Wait forWait forisACK(rcvpkt,1) )ACKcall 0 from0udt send(sndpkt)abovesender FSMfragmentrdt rcv(rcvpkt) &&(corrupt(rcvpkt) has seq1(rcvpkt))udt send(sndpkt)Wait for0 frombelowrdt rcv(rcvpkt)&& notcorrupt(rcvpkt)&& isACK(rcvpkt,0)receiver FSMfragmentrdt rcv(rcvpkt) && notcorrupt(rcvpkt)&& has seq1(rcvpkt)3-33extract(rcvpkt,data)deliver data(data)sndpkt make pkt(ACK1, chksum)Transport Layerudt send(sndpkt)Λ
rdt3.0: channels with errors and lossNew assumption: underlyingchannel can also lose packets(data or ACKs)}checksum, seq. #, ACKs,retransmissions will be of help,but not enoughApproach: sender waits“reasonable” amount of timefor ACK}}}3-34retransmits if no ACK received inthis timeif pkt (or ACK) just delayed (notlost):} retransmission will be duplicate,but use of seq. #’s alreadyhandles this} receiver must specify seq # ofpkt being ACKedrequires countdown timerTransport Layer
rdt3.0 senderrdt send(data)sndpkt make pkt(0, data, checksum)udt send(sndpkt)start timerrdt rcv(rcvpkt)Λrdt rcv(rcvpkt) &&( corrupt(rcvpkt) isACK(rcvpkt,1) )ΛWaitforACK0Wait forcall 0fromaboverdt rcv(rcvpkt)&& notcorrupt(rcvpkt)&& isACK(rcvpkt,1)timeoutudt send(sndpkt)start timerrdt rcv(rcvpkt)&& notcorrupt(rcvpkt)&& isACK(rcvpkt,0)stop timerstop timertimeoutudt send(sndpkt)start timerrdt rcv(rcvpkt) &&( corrupt(rcvpkt) isACK(rcvpkt,0) )Λ3-35WaitforACK1Wait forcall 1 fromaboverdt rcv(rcvpkt)Λrdt send(data)sndpkt make pkt(1, data, checksum)udt send(sndpkt)start timerTransport Layer
rdt3.0 in action3-36Transport Layer
rdt3.0 in action3-37Transport Layer
rdt3.0: stop-and-wait operationsenderreceiverfirst packet bit transmitted, t 0last packet bit transmitted, t L / RRTTfirst packet bit arriveslast packet bit arrives, send ACKACK arrives, send nextpacket, t RTT L / RLink UtilizationFraction of time the sender is busy sending traffic3-38Transport Layer
Performance of rdt3.0}}rdt3.0 works, but performance is very badex: 1 Gbps link, 15 ms prop. delay, 8000 bit packet:dtrans U sender: utilization fraction of time sender busy sendingU 3-39L 8000bits 8 microseconds9R 10 bpssender L/RRTT L / R .00830.008 0.00027microseconds 1kB pkt/30 msec - 33kB/sec throughput over 1 Gbps linknetwork protocol limits use of physical resources!Transport Layer
Pipelined protocols***Pipelining: sender allows multiple, “in-flight”, yet-to-beacknowledged pkts}}}range of sequence numbers must be increasedbuffering at sender and/or receiverTwo generic forms of pipelined protocols: go-Back-N, selectiverepeat3-40Transport Layer
Pipelining: increased utilizationsenderreceiverfirst packet bit transmitted, t 0last bit transmitted, t L / Rfirst packet bit arriveslast packet bit arrives, send ACKlast bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACKRTTACK arrives, send nextpacket, t RTT L / RIncrease utilizationby a factor of 3!U3-41sender 3*L/RRTT L / R .02430.008 0.0008microsecondsTransport Layer
Pipelining ProtocolsGo-back-N: overview} sender: up to N unACKedpkts in pipeline} receiver: only sendscumulative ACKs}}doesn’t ACK pkt if there’s a gapsender: has timer for oldestunACKed pkt}Selective Repeat: overview} sender: up to N unACKedpackets in pipeline} receiver: ACKs individual pkts} sender: maintains timer foreach unACKed pkt}if timer expires: retransmit onlyunACKed packetif timer expires: retransmit allunACKed packets3-42Transport Layer
Go-Back-NSender:}}k-bit seq # in pkt header (not limited to 0/1)“sliding window” of up to N, consecutive unACKed pkts allowed ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK”may receive duplicate ACKs (see receiver) only one timer for all in-flight pkt (started at the oldest nonacked packet) timeout(n): retransmit pkt n and all higher seq # pkts in window 3-43Transport Layer
GBN: sender extended FSMrdt send(data)Λbase 1nextseqnum 1if (nextseqnum base N) {sndpkt[nextseqnum] make pkt(nextseqnum,data,chksum)udt send(sndpkt[nextseqnum])if (base nextseqnum)start timernextseqnum }elserefuse data(data)Waitrdt rcv(rcvpkt)&& corrupt(rcvpkt)3-44timeoutstart timerudt send(sndpkt[base])udt send(sndpkt[base 1]) udt send(sndpkt[nextseqnum-1])base getacknum(rcvpkt) 1if (base nextseqnum)stop timerelsestart timerTransport Layer
GBN: receiver extended FSMdefaultudt send(sndpkt)ΛWaitexpectedseqnum 1sndpkt make pkt(expectedseqnum,ACK,chksum)rdt rcv(rcvpkt)&& notcurrupt(rcvpkt)&& a)deliver data(data)sndpkt make pkt(expectedseqnum,ACK,chksum)udt send(sndpkt)expectedseqnum ACK-only: always send ACK for correctly-received pkt withhighest in-order seq #}}}out-of-order pkt:}}3-45may generate duplicate ACKsneed only remember expectedseqnumdiscard (don’t buffer) - no receiver buffering!Re-ACK pkt with highest in-order seq #Transport Layer
GBN inaction3-46Transport Layer
Selective Repeat}receiver individually acknowledges all correctly receivedpkts}}sender only resends pkts for which ACK not received}}buffers pkts, as needed, for eventual in-order delivery to upperlayersender timer for each unACKed pktsender window}}3-47N consecutive seq #’sagain limits seq #s of sent, unACKed pktsTransport Layer
Selective repeat: sender, receiver windows3-48Transport Layer
Selective repeatsenderdata from above :}if next available seq # in window,send pkttimeout(n):}resend pkt n, restart timerACK(n) in [sendbase,sendbase N]:}}mark pkt n as receivedif n smallest unACKed pkt,advance window base to nextunACKed seq #3-49receiverpkt n in [rcvbase, rcvbase N-1] send ACK(n) out-of-order: buffer in-order: deliver (alsodeliver buffered, in-orderpkts), advance window tonext not-yet-received pktpkt n in [rcvbase-N,rcvbase-1] ACK(n)otherwise: ignoreTransport Layer
Selective repeat in action3-50Transport Layer
Selective repeat:dilemmaExample:}}}}seq #’s: 0, 1, 2, 3window size 3receiver sees no differencein two scenarios!incorrectly passes duplicatedata as new in (a)Q: what relationship betweenseq # size and windowsize?window size ½Seq# size3-51Transport Layer
TCP: Overview}point-to-point:}}socketdoorone sender, one receiverfull duplex data:}}no “message boundaries”}TCP congestion and flowcontrol set window sizesend & receive buffersapplicationwrites data}applicationreads dataTCPsend bufferTCPreceive bufferhandshaking (exchange ofcontrol msgs) init’s sender,receiver state before dataexchangeflow controlled:}socketdoorbi-directional data flow insame connectionMSS: maximum segment sizeconnection-oriented:}pipelined:}}}reliable, in-order bytestream:}}RFCs: 793, 1122, 1323, 2018, 2581sender will not overwhelmreceiversegment3-52Transport Layer
TCP segment structure32 bitsURG: urgent data(generally not used)ACK: ACK #validPSH: push data now(generally not used)RST, SYN, FIN:connection estab(setup, teardowncommands)Internetchecksum(as in UDP)3-53source port #dest port #sequence numberacknowledgement numberhead notlen used U A P R S FchecksumReceive windowUrg data pointerOptions (variable length)applicationdata(variable length)Transport Layercountingby bytesof data(not segments!)# bytesrcvr willingto accept
TCP seq. #’s and ACKsSeq. #’s:} byte stream “number”of first byte in segment’sdataACKs:} seq # of next byteexpected from otherside} cumulative ACKQ: how receiver handles outof-order segments} A: TCP spec doesn’t say,- up to implementerHost BHost AUsertypes‘C’Seq 4Sehost ACKsreceiptof echoed‘C’2, ACK 79, d, ACq 79Seq 4K 4ata ‘C’ta 3, da‘C’host ACKsreceipt of‘C’, echoesback ‘C’3, ACK 80simple telnet scenario3-54Transport Layertime
TCP: retransmission scenariosHost Aytes data 100XACKlossSeq 92, 8 bytes data100Sendbase 100SendBase 120 ACKSendBase 100time3-55Host BSeq 9Seq 92 timeout2, 8 bSendBase 120lost ACK scenarioSeq 2, 8 b100,Seq 9Seq 92 timeoutSeq 9timeoutHost
CSCI 6760 - Computer Networks Spring 2017 Instructor: Prof. Roberto Perdisci perdisci@cs.uga.edu source: computer-networks-webdesign.com These slides are adap
The AirEngine 6760-X1 uses built- in smart antennas to move Wi-Fi signals with users, significantly enhancing users' wireless network experience. AirEngine 6760- X1 and AirEngine 6760-X1E provide 10GE uplink optical and electrical ports, allowing customers to select dif
CSCI 561 – Theory of Computation Dr. Neil T. Dantam CSCI-561, Colorado School of Mines Fall 2021 Dantam (Mines CSCI-561) Intro Fall 2021 1/32
ContourLine Combi-Steam Oven DGC 6760 XXL DGC 6760 XXL Page 2 of 7 SPECIFICATIONS DGC 6760 XXL — Item 23
This Software Requirements Specification details the software requirements for the FS CSCI. The FS CSCI is composed of the following Computer Software Components (CSCs): 1. Executive (0/S services, Device Drivers, Interrupt Handling, Initialization) 2. Prom Capability an.d System Initialization 3. Command Processing
6760-230-010 1.0mm tip 6760-230-005 0.5mm tip. Spring force . elevates control and . tactile feedback. Sleek bayonet design . improves visualization. Flexible lightweight cord and remote connection plug . helps achieve balance. Single use. ensur
DCAP406 COMPUTER NETWORKS Sr. No. Description 1. Introduction to Computer Networks: uses of computer networks, 2. Network hardware, network software, Reference models, Example networks 3. Physical Layer : Theoretical Basis for Data Communication, Guided Transmission Media, Wireless Transmission, Communication Satellites 4.
Model 6760 Maximum Operating Pressure: 160 PSI (1.1 MPa, 11 bar) System Description Sharpe’s DRYAIRE Desiccant Air Drying System is the painter’s insurance for removing dirt, water, oil, and uncon-densed moisture from compressed air lin es. Sharpe’s Model 6760 File Size: 910KB
EDUQAS A LEVEL - COMPONENT 1 BUSINESS OPPORTUNITIES AND FUNCTIONS SUMMER 2018 MARK SCHEME SECTION A Q. Total 1 Give one example of a business using batch production and describe two benefits of this method of production. Award 1 mark for an appropriate example. AO1: 1 mark Indicative content: A baker making loaves of bread; a clothing manufacturer making batches of a particular garment; a .
