Wilamowski B.M., Irwin J.D. The Industrial Electronics Handbook. Second Edition: Industrial Communication Systems

Подождите немного. Документ загружается.

60-10 Industrial Communication Systems

references

[C02–1].D..Comer,.Internetworking with TCP/IP Vol. 1: Principles, Protocols, and Architecture,.5th.edn.,.

Pren

tice

.Ha

ll,

.Up

per

.Saddle.Ri

ver,

.NJ,.2005.

[C02–3]

. D.. Com

. et. al.,. Int

ernetworking with TCP/IP,

. Vol

. III:. Clien

t-Server Programming and

Applications, Linux/Posix Sockets Version,

.Pr

entice

.Ha

ll,

.Up

per

.Saddle.Ri

ver,

.NJ,.2000.

[F10]

.B.A..Fo

rouzan,

.TCP/IP P

rotocol Suite,

.4th.edn.,.McG

raw-Hill,

.Ne

.Yo

rk,

.2010.

[GW03]

.A..Le

on-Garcia,

.I..Wid

jaja,

.Co

mmunication Networks,

.2nd.edn.,.McG

raw-Hill,

.Ne

.Yo

rk,

.2003.

[IAN

.We

.Si

.fo

.IAN

A - Internet Assigned Numbers Authority,

.ht

tp://www.iana.org/

[PD07]

.L.L..Peter

son,

.B.S..Dav

ie,

.Com

puter Networks: A System Approach,

.4th.edn.,.Mor

gan

.Kauf

mann

Publi

shers,

.San.Fra

ncisco,

.CA,.2007.

[RFC]

.We

.Si

.fo

.RFC Edi

tor,

.ht

tp://www.rfc-editor.org/

[RFC2147]

.D..Bor

man

.et.al.,.TCP.and.UDP.over.IPv6.Jumb

ograms,

.May.1997..htt

p://www.rfc-editor.org/

[RFC2675]

.D..Bo

rman

.et.al

.IPv6.Jum

bograms,

.Augu

.1999..ht

tp://www.rfc-editor.org/

[RFC3171]

.Z..Al

bana,

.K..Alm

eroth,

.D..Me

yer,

.M..Sc

hipper,

.IAN

.Guide

lines

.fo

.IPv4.Mu

lticast

.Addr

ess

Assig

nments,

.Augu

.2001..ht

tp://www.rfc-editor.org/

[RFC3493]

.R..Gil

ligan

.et.al.,.Basic.Soc

ket

.Int

erface

.Exten

sions

.for.IPv6,.Feb

ruary

.2003..htt

p://www.rfc-

editor.org/

[STD2]

.J..Re

ynolds,

.J..Pos

tel,

.As

signed

.Num

bers,

.Oc

tober

.1994..ht

tp://www.rfc-editor.org/

[STD5]

.J..Pos

tel,

.In

ternet

.Pr

otocol,

.Sep

tember

.1981..ht

tp://www.rfc-editor.org/

[STD6]

.RFC0768/STD0006,.J..Pos

tel,

.Us

.Da

tagram

.Pr

otocol,

.Augu

.1980..ht

tp://www.rfc-editor.org/

[STD33]

.K..Sol

lins,

. e.Tp.Pro

tocol

.(Rev

ision

.2),.Jul

.199

.htt

p://www.rfc-editor.org/

[STD62]

.D..Har

rington,

.R..Pre

suhn,

.B..Wij

nen,

.An.Arc

hitecture

.for.Desc

ribing

.Sim

ple

.Net

work

.Man

agement

Pro

tocol

.(SN

MP)

.Man

agement

.Fra

meworks,

.Dec

ember

.200

.htt

p://www.rfc-editor.org/

FIGURE 60.8 (continued)

61-1

61.1 Introduction

Transmission.control.protocol.(TCP).is.a.part.of.TCP/Internet.protocol.(IP).suite.[STD7,C02-1,F10,.

GW03,

PD07].

.It.prov

ides

.full.tran

sport

.laye

.serv

ices

.to.appl

ications.

.It.belo

ngs

.to.the.tran

sport

.laye

.in.

the.TCP/

.suit

.mode

.as.show

.in.Figu

.61.1

.TCP.is.more.comp

licated

.than.user.data

gram

.proto

col

(UDP

)

.and.prov

ides

.a.reli

able

.conn

ection

.betw

een

.both.ends.of.tran

smission.

. is.conn

ection

.need

to.be.set.up,.main

tained,

.and.torn.down

. e.proto

col

.divi

des

.a.stre

.of.data.into.unit

.of.limi

ted

size.call

.segm

ents.

. ese.segm

ents

.are.reas

sembled

.in.a.reli

able

.way.at.the.othe

.end..Reli

ability

.is.

achi

eved

.by.asse

mbling

.segm

ents

.by.pres

erving

.thei

.orig

inal

.sequ

ence,

.and.arra

nging

.for.retr

ansmis-

sion

.of.lost.or.corr

upted

.data

.Whil

.the.unde

rlying

.IP.prov

ides

.logi

cal

.addr

essing

.of.segm

ents

.and.is.

resp

onsible

.for.thei

.tran

smission

.thro

ugh

.netw

orks

.[STD

5],

.TCP.prov

ides

.addi

tional

.addr

essing

.that.

allo

.sett

ing

.up.conn

ections

.for.mult

iple

.appl

ications

.and.serv

ices

.on.the.same.end..Each.appl

ication

seek

ing

.TCP.conn

ection

.is.assig

ned

.one.or.more.numbe

.(one.numbe

.per.conn

ection)

.that.are.call

port.numb

ers.

.Fig

ure

.61.

.ill

ustrates

.the.con

cept

.of.por

.numb

ers.

TCP

.prov

ides

.a.logi

cal

.full.dupl

.conn

ection

.betw

een

.two.appl

ication

.laye

.proc

esses.

. e.conn

ec-

tion

.is.perc

eived

.as.a.conn

ection-oriented,

.reli

able,

.in-s

equence

.byte

-stream

.serv

ice.

. e.proto

col

.also.

allo

.the.reci

pient

.of.data.to.cont

rol

.the.rate.at.whic

.the.send

.tran

smits

.data.to.avoi

.bue

.over

ow.

•

. Conn

ection-oriented

.show

.that.the.conn

ection

.need

.to.be.esta

blished

.and.its.para

meters

.nego

ti-

ated

.betw

een

.the.two.proc

esses.

. is.nego

tiation

.is.perf

ormed

.by.send

ing

.tran

smission

.cont

rol

bloc

.(TCB

.At.the.end.of.the.tran

smission,

.the.conn

ection

.must.be.torn.down

.TCP.term

inates

each.dire

ction

.of.the.conn

ection

.sepa

rately,

.whic

.allo

.the.data.ow.to.cont

inue

.even.aer.the.

othe

.dir

ection

.has.bee

.clo

sed.

•

. Reli

able

.indi

cates

.that.eith

.all.data.are.deli

vered

.or.the.conn

ection

.is.brok

en.

.TCP.is.desig

ned

to.work.over.the.IP.and.thus.it.does.not.assu

.that.the.unde

rlying

.netw

ork

.serv

ices

.are.reli

able.

To.ensu

.reli

ability,

.each.chun

.of.data.are.numbe

red,

.and.a.sele

ctive

.autom

atic

.repe

.requ

est

(ARQ

)

.is.emp

loyed

.to.req

uest

.ret

ransmission

.of.los

.or.cor

rupt

.dat

.chu

nk.

Transmission Control

Protocol—TCP

61.1. Introduction..................................................................................... 61-1

61.2

. Proto

col

.Ope

ration.......................................................................... 61-3

TCP.Segment. •. Port.Number.Assignments. •. Connection.

Establishment. •. Maintaining.the.Open.Connection. •. Flow.Control.

and.Sliding.Window.Protocol. •. Improving.Flow.Control. •. Error.

Control. •. Congestion.Control. •. Connection.Termination

61.3. State.Diagram..................................................................................61-14

61.4

. Prog

ramming

.Sam

ples..................................................................61-14

References................................................................................................... 61-17

Aleksander

Malinowski

Bradley University

Bogdan M.

Wilamowski

Auburn University

61-2 Industrial Communication Systems

•. In-sequence.shows.that.all.data.are.guaranteed.to.be.received.by.the.end.receiving.process.in.the.

same.order.that.they.were.sent..Sequencing.is.implemented.by.the.same.mechanism.that.is.used.

for.missing.data.chunk.detection..All.received.data.are.placed.in.a.receiving.buer.in.location.

corresponding.to.the.data.chunk.number.. e.process.that.receives.data.reads.it.from.that.buer.

in.a.correct.sequence.

•

. Byte-stream.oriented.implies.that.the.connection.can.be.perceived.as.continuous.stream.of.data.

regardless.of.the.fact.that.the.underlying.network.services.may.transmit.data.in.chunks.. ose.

data.chunks.may.be.of.various.sizes.and.may.have.maximum.size.limit.. e.sending.process,.

however,.may.send.data.either.continuously.or.in.bursts..All.data.to.be.sent.are.placed.in.the.send-

ing

.buer..Data.from.the.buer.are.partitioned.into.chunks,.which.are.called.segments.according.

to.algorithms.of.TCP,.and.then.they.are.sent.over.the.network..On.the.receiving.side,.the.data.

are.placed.in.the.receiving.buer.in.an.appropriate.sequence.as.mentioned.earlier.. e.receiving.

process.may.read.data.either.as.chunks.or.as.byte.aer.byte.

•

. Full duplex.indicates.that.each.party.involved.in.the.transmission.has.control.over.it..For.example,.

any.side.can.send.data.at.any.time.or.terminate.the.connection.

The

.TCP.is.standardized.by.Internet Society,.which.is.an.independent.international.nonprofit.

organization.. A. complete. information. about. TCP-related. standards.is. published.by.RFC Editor.

[RFC]..Several.relevant.RFC.articles.as.well.as.further.reading.materials.are.listed.at.the.end.of.this.

article.

Application layer

SMTP FTP

TCP

IGMP ICMP

Physical layer

Data link layer

Network layer

Transport layer

Underlying LAN or WAN technology

ARP RARP

UDP

DNS SNMP BOOTP

FIGURE 61.1 UDP.and.TCP/IP.in.the.TCP/IP.protocol.suite.model.

TCPTCP

Telnet

(client)

Telnet

(server)

63158

FIGURE 61.2 Process.to.process.communication.

Transmission Control Protocol—TCP 61-3

61.2 Protocol Operation

Before.data.transfer.begins,.TCP.establishes.a.connection.between.two.application.processes.by.setting.

up.the.protocol.parameters.. ese.parameters.are.stored.in.a.structure.variable.called.TCB..Once.the.

connection.is.established,.the.data.transfer.may.begin..During.the.transfer,.parameters.may.be.modi-

ed

.to.improve.eciency.of.transmission.and.prevent.congestion..In.the.end,.the.connection.is.closed..

Under.certain.circumstances,.connection.may.be.terminated.without.formal.closing.

61.2.1 tCP Segment

Although.TCP.is.byte-stream.oriented,.connection.and.buering.take.care.of.the.disparities.among.

the.speed.of.preparing.data,.sending.data,.and.consuming.of.data.at.the.other.end,.one.more.step.is.

necessary.before.data.are.sent.. e.underneath.IP.layer.that.takes.care.of.sending.data.through.the.

entire.network.sends.data.in.packets,.not.as.a.stream.of.bytes..Sending.one.byte.in.a.packet.would.be.

very.inecient.due.to.the.large.overhead.caused.by.headers.. erefore,.data.are.grouped.into.larger.

chunks.called.segments..Each.segment.is.encapsulated.in.an.IP.datagram.and.then.transmitted..Each.

TCP.segment.follows.the.same.format.that.is.shown.in.Figure.61.3.[STD7]..Each.segment.consists.of.a.

header.that.is.followed.by.options.and.data.. e.meaning.of.each.header.eld.will.be.discussed.now,.and.

its.importance.is.illustrated.in.the.following.sections,.which.show.phases.of.a.typical.TCP.connection.

•

. Source port address:. is.is.a.16.bit.eld.that.contains.a.port.number.of.the.process.that.sends.

options.or.data.in.this.segment.

•

. Destination port address:. is.is.a.16.bit.eld.that.contains.a.port.number.of.the.process.that.is.

supposed.to.receive.options.or.data.carried.by.this.segment.

Destination port number

16 bits

Source port number

16 bits

Sequence number

32 bits

Acknowledgment number

32 bits

Window size

16 bits

Urgent pointer

16 bits

Checksum

16 bits

HLEN

4 bits

Reser-

ved

6 bits

Header Data

u a p

r s

sc s y i

g k h t n

Options and padding

URG: Urgent pointer is vaild

ACK: Acknowledgment is valid

PSH: Request for push

RST: Reset the connection

SYN: Synchronize sequence number

FIN: Terminate the connection

URG ACK PSH RST SYN FIN

FIGURE 61.3 TCP.segment.format.

61-4 Industrial Communication Systems

•. Sequence number:. is.is.a.32.bit.eld.that.contains.the.number.assigned.to.the.rst.byte.of.

data.carried.by.this.segment..During.the.establishment.of.connection.each.side.generates.its.

own.random.initial.sequence.number.(ISN).. e.sequence.number.is.then.increased.by.one.with.

every.1.byte.of.data.sent..For.example,.if.a.previous.segment.had.a.sequence.number.700.and.had.

200bytes.of.data.then.sequence.number.of.the.next.segment.is.900.

•

. Acknowledgment number:. is.is.a.32.bit.eld.that.contains.the.sequence.number.for.the.next.seg-

ment

.that.is.expected.to.be.received.from.the.other.party..For.example,.if.the.last.received.segment.

had.a.sequence.number.700.and.had.200.bytes.of.data,.then.the.acknowledgment.number.is.900.

•

. Header length:. is.4.bit.eld.contains.the.total.size.of.the.segment.header.divided.by.4..Since.

headers.may.be.20–60.bytes.long,.the.value.is.in.the.range.5–15.

•

. Reserved:. is.6.bit.eld.is.reserved.for.future.use.

•

. Control:. is.6.bit.eld.contains.transmission.control.ags.

•

. URG:.Urgent..If.the.bit.is.set,.then.the.urgent.pointer.is.valid.

•

. ACK:.Acknowledgment..If.the.bit.is.set.then.the.acknowledgment.number.is.valid.

•

. PSH:.Push..If.the.bit.is.set,.then.the.other.party.should.not.buer.the.outgoing.data.but.send.it.

immediately,.as.it.becomes.available,.without.buering.

•

. RST:.Reset..If.the.bit.is.set,.then.the.connection.should.be.aborted.immediately.due.to.abnormal.

condition.

•

. SYN:.Synchronize.. e.bit.is.set.in.the.connection.request.segment.when.the.connection.is.being.

established.

•

. FIN:.Finalize..If.the.bit.is.set,.it.means.that.the.sender.does.not.have.anything.more.to.send,.and.

that.the.connection.may.be.closed.. e.process.will.still.accept.data.from.the.other.party.until.the.

other.party.also.sends.FIN.

•

. Window size:. is.16.bit.eld.contains.information.about.the.size.of.the.transmission.window.that.

the.other.party.must.maintain..Window.size.will.be.explained.and.illustrated.later.

•

. Checksum:. is.16.bit.eld.contains.the.checksum.. e.checksum.is.calculated.by

•

. Initially.lling.it.with.0s

•

. Adding.a.pseudoheader.with.information.from.IP,.as.illustrated.in.Figure.61.4.

•

. Treating.the.whole.segment.with.the.pseudoheader.prepended.as.a.stream.of.16.bit.

numbers..If.the.number.of.bytes.is.odd,.0.is.appended.at.the.end.

Pseudoheader

Header

32 bit source IP address

All 0s 8 bit protocol (6)

Source port Destination port

Sequence number

Acknowledgment number

HLEN

Reserved

Control

Window size

Urgent pointer

Checksum

Options (optional) and data

(padding must be added to make the

data a multiple of 16 bits)

16 bit TCP total length

32 bit destination IP address

FIGURE 61.4 Pseudoheader.added.to.the.TCP.datagram.

Transmission Control Protocol—TCP 61-5

•. Adding.all.16.bit.numbers.using.1s.complement.binary.arithmetic.

•

. Complementing.the.result.. is.complemented.result.is.inserted.into.the.checksum.eld.

•

. Checksum verication:. e.receiver.calculates.the.new.checksum.for.the.received.packet,.which.

includes.the.original.checksum,.aer.adding.the.pseudoheader.(see.Figure.61.4)..If.the.new.check-

sum

.is.nonzero.then.the.packet.is.corrupt.and.is.discarded.

•

. Urgent pointer:. is.16.bit.eld.is.used.only.if.the.URG.ag.is.set..It.denes.the.location.of.the.last.

urgent.byte.in.the.data.section.of.the.segment..Urgent.data.are.those.that.are.sent.out-of-sequence..

For.example,.telnet.client.sends.a.break.character.without.queuing.it.in.the.sending.buer.

•

. Options:. ere.can.be.up.to.40.bytes.of.options.appended.to.the.header.. e.options.are.padded.

inside.with.0s.so.that.the.total.number.of.bytes.in.the.header.is.divisible.by.4.. e.possible.options.

are.listed.below.and.are.illustrated.in.Figure.61.5:

(4)

Code:2

00000010

Length:4

00000100

1 byte 1 byte 2 bytes

Maximum segment size

(3)

Code:1

00000001

a. End of option b. Used to align beginning of an option c. Used to align the next option

A 7-byte option

An 8-byte option

All 11-byte option

(5)

Length:3

00000011

Code:3

00000011

Scale factor

1 byte 1 byte 1 bytes

(6)

Length:10

00001010

Code:8

00001000

Timestamp value

Timestamp echo reply

(1)

Options

Single-byte

End of option

No operation

Maximum segment size

Window scale factor

Timestamp

Multiple-byte

(2)

Options

Data

a. End of option b. Used for padding

END-OP

Code:0

00000000

FIGURE 61.5 TCP.options:.1..classication;.2..end.of.options;.3..no.operation.(used.for.padding);.4..setting.

maximum.segment.size;.5..setting.window.scale.factor;.6..time.stamp.

61-6 Industrial Communication Systems

•. No operation:.1.byte.option.used.as.ller.between.the.options.and.as.padding.

•

. End

of options:

.1.byt

.opti

.use

.as.pad

ding

.at.the.end.of.opti

ons

.le

.Dat

.por

tion

.of.

the.se

gment

.fo

llows

.im

mediately.

•

. Max

imum segment size (MSS):

.Opt

ion

.de

nes

.the.max

imum

.siz

.of.a.chu

.of.dat

tha

.can.be.rec

eived.

.It.ref

ers

.to.the.siz

.of.dat

.not.the.who

.seg

ment.

.It.is.use

.onl

dur

ing

.the.est

ablishment

.of.the.con

nection.

. e.rec

eiving

.par

.de

nes

.the.max

imum

siz

.of.the

datagram

.sen

.by.the.sen

der.

.If.not.spe

cied,

.the.def

ault

.max

imum

.is.536

Bec

ause

.the.len

gth

.of.the.dat

agram

.is.not.spe

cied

.in.the.TCP.hea

der,

.the

.is.no.len

gth

lim

itation

.for.an.ind

ividual

.TCP.pac

ket.

.How

ever,

.the.MSS.val

.tha

.is.neg

otiated

.at.

the.beg

inning

.of.the.con

nection

.lim

its

.the.lar

gest

.TCP.pac

ket

.tha

.can.be.sen

.and.the.

Urg

ent

.Poi

nter

.can

not

.ref

erence

.dat

.bey

ond

.65,

535

.byt

es.

.MSS.val

.of.65,

535

.is.tre

ated

as.in

nity

.[RF

C2675]

.[RF

C2147].

•

. Win

dow scale factor:

.For.hig

.thr

oughput

.cha

nnels

.the.win

dow

.size.fro

.the.seg

ment

hea

der

.(16.bit

.max

imum

.65,

535)

.may.not.be.su

cient.

. is.3.byt

.opti

.de

nes

.the.

mul

tiplication

.fac

tor

.for.the.win

dow

.size

. e.act

ual

.win

dow

.size.is.com

puted

.usin

.the.

fol

lowing

.fo

rmula

Actual window size Window size

window scale factor

= ⋅2

•. Tim

e stamp:

. is.is.a.10.byt

.opt

ion

.tha

.hol

.the.tim

.sta

.val

.of.tra

nsmitted

.seg

ment.

.Whe

.an.ack

nowledgment

.is.sen

.the.sam

.val

.is.use

. is.all

ows

.the.ori

gi-

nal

.sen

der

.to.det

ermine

.the.opt

imal

.ret

ransmission

.tim

.bas

.on.the.pac

ket

.rou

tri

.tim

61.2.2 Port Number assignments

In.order.to.provide.a.platform.for.an.independent.process.addressing.on.a.host,.each.connection.of.the.

pro

cess

.to.the.net

work

.is.assi

gned

.a.16.bit.numb

er.

. er

.are.thr

.cat

egories

.of.por

.numb

ers:

.wel

known

.(0–

1,023),

.reg

istered

.(1,

024–49,151),

.and.eph

emeral

.(49

,152–6,553).

.Wel

l-known ports

.hav

.bee

his

torically

.assi

gned

.to.com

mon

.ser

vices.

.Som

.ope

rating

.sys

tems

.req

uire

.tha

.the.pro

cess

.tha

.uti

lizes

.tho

.por

.mus

.hav

.adm

inistrative

.pri

vileges.

. is.req

uirement

.was.his

torically

.cre

ated

.to.avo

hac

kers

.run

ning

.ser

ver

.imp

osters

.on.mul

tiuser

.sys

tems.

.Wel

l-known

.por

.are.reg

istered

.and.con

trolled

.by.Int

ernet

.Assi

gned

.Numb

ers

.Aut

hority

.(IA

NA)

.[IA

NA,STD2].

.Tab

.61.

.sho

.wel

l-known

por

.com

monly

.use

.by.TCP

.Reg

istered ports

.are.als

.reg

istered

.by.IAN

.to.avo

.pos

sible

.con

icts

amo

.di

erent

.app

lications

.att

empting

.to.use.the.sam

.por

.for.lis

tening

.to.inc

oming

.con

nections.

Eph

emeral

.por

.are.als

.cal

led

.dyn

amic

.por

ts.

. es

.por

.are.use

.by.out

going

.con

nections

.tha

.are.

typ

ically

.assi

gned

.to.the.rs

.ava

ilable

.por

.abo

.49,

151.

.Man

.ope

rating

.sys

tems

.may.not.fol

low

.IAN

rec

ommendations

.and.tre

.the.reg

istered

.por

.ran

.as.eph

emeral.

.For.exa

mple,

.BSD.use

.por

.1,0

thr

ough

.4,9

.as.eph

emeral

.por

ts,

.man

.Lin

.ker

nels

.use.32,7

68–61,000,

.Wind

ows

.use.1,0

25–5,000,

whi

.Fr

eeBSD

.fo

llows

.IA

.po

.ra

nge.

For

.exa

mple,

.a.Web.Ser

ver

.usu

ally

.use

.wel

l-known

.por

.80,.a.pro

xyserver

.may.typ

ically

.use.reg

is-

tered

.por

.8,0

00,

.8,0

08,

.or.8,0

80,

.a.Web.bro

wser

.use

.mul

tiple

.eph

emeral

.por

ts,

.one.for.eac

.new.con

nection

.op

.to.do

wnload

.a.co

mponent

.of.a.We

.pa

ge.

.Ep

hemeral

.po

rts

.ar

.ev

entually

.re

cycled.

61.2.3 Connection Establishment

Before.data.transfer.begins,.TCP.establishes.a.connection.between.two.application.processes.by.set-

ting

.up.the.pro

tocol

.par

ameters.

. es

.par

ameters

.are.sto

red

.in.a.str

ucture

.var

iable

.cal

led

.TCB

Transmission Control Protocol—TCP 61-7

Before.the.two.parties—called.here.as.host.A.and.host.B—can.start.sending.data,.four.actions.must.

be.performed:

. 1..Host.A.sends.a.segment.announcing.that.it.wants.to.establish.connection.. is.segment.includes.

initial.information.about.trac.from.A.to.B.

. 2.. Host.B.sends.a.segment.acknowledging.the.request.received.from.A.

. 3..Host.B.sends.a.segment.with.information.about.trac.from.B.to.A.

. 4.. Host.A.sends.a.segment.acknowledging.the.request.received.from.B.

.second.and.the.third.steps.can.be.combined.into.one.segment.. erefore,.the.connection.estab-

lishment

.described.is.also.called.three-way.handshaking..Figure.61.6.illustrates.an.example.of.segment.

Sender Receiver

Segment 1: SYN

Segment 2: SYN+ACK

Segment 3: ACK

seq:11,200, ack:---

seq:14,800, ack:11,201

seq:11,201, ack:14,801

Time Time

FIGURE 61.6 ree-way.handshaking.during.connection.establishment.

TABLE 61.1 Common.Well-Known.Ports.Used.with.TCP

Port Protocol Description RFC/STD.#

7 Echo Echoes

.a.received.data.back.to.its.sender STD20

9 Discard Discards

.any.data.that.are.received STD21

13 Daytime Returns

.the.date.and.the.time.in.ASCII.string.format STD25

19 Chargen Sends

.back.arbitrary.characters.until.connection.closed STD22

20 FTP

.Data File.Transfer.Protocol.(data.transmission.connection,.unencrypted) STD9

21 FTP

.Control File.Transfer.protocol.(control.connection,.unencrypted) STD9

22 SSH Secure

.Shell.(SSH)—used.for.secure.logins,.le.transfers.(scp,.sp),.

and.port.forwarding

RFC4250-4256

23 Telnet Telnet

.(unencrypted) STD8,.STD27-32

25 SMTP Simple

.Mail.Transfer.Protocol.(sending.email) STD10

37 Time Returns

.the.current.time.in.seconds.since.1/1/1900.in.a.32.bit.format STD26

53 Nameserver Domain

.Name.Service STD13

80 HTTP Hypertext

.Transfer.Protocol RFC2616

110 POP3 Post

.Oce.Protocol.3.(email.download) STD53

111 RPC SUN

.Remote.Procedure.Call RFC5531

143 IMAP Interim

.Mail.Access.Protocol.v2.(email.access) RFC2060

443 SHTTP Secure

.Hypertext.Transfer.Protocol RFC2660

995 POP3 POP3

.over.TLS/SSL RFC2595

61-8 Industrial Communication Systems

exchange.during.connection.establishment..Among.the.two.programs.that.are.involved.in.the.connection,.

the.ser

ver

.pro

gram

.is.the.one.tha

.pas

sively

.wai

.for.ano

ther

.par

.to.con

nect.

.It.wil

.be.cal

led

.sho

rtly

as.the.ser

ver.

.It.tel

.the.und

erlying

.TCP.lib

rary

.in.its.sys

tem

.tha

.it.is.rea

.to.acc

ept

.a.con

nection.

. e.

pro

gram

.tha

.act

ively

.see

.con

nection

.is.cal

led

.a.cli

ent

.pro

gram.

.It.wil

.be.cal

led

.sho

rtly

.as.the.cli

ent.

 e.cli

ent

.tel

.the.und

erlying

.lib

rary

.in.its.sys

tem

.tha

.it.nee

.to.con

nect

.to.a.par

ticular

.ser

ver

.tha

.is.

de

ned

.by.th

.co

mputer

.IP.ad

dress

.an

.th

.de

stination

.po

.nu

mber.

. 1.. e.cli

ent

.sen

.the.rs

.seg

ment

.tha

.inc

ludes

.the.sou

rce

.and.des

tination

.por

.wit

.SYN.bit.set

. e.

seg

ment

.als

.con

tains

.the.ini

tial

.val

.of.Seq

uence

.Num

ber,

.whic

.is.als

.cal

led

.ISN.tha

.wil

.be.use

by.the.cli

ent

.in.this.conn

ection.

. e.cli

ent

.may.als

.sen

.som

.opt

ions

.as.nec

essary,

.for.exa

mple,

.to.

alter.the.window.size,.or.maximum.segment.size.in.order.to.change.their.values.from.default.

. 2.. e.serv

.send

.the.secon

.segm

ent

.tha

.has.bot

.ACK.and.SYN.bit.sets

. is.is.don

.in.ord

.to.

bot

.ack

nowledge

.rece

iving

.the.rs

.segm

ent

.fro

.the.cli

ent

.(AC

.and.to.ini

tialize

.the.sequ

ence

num

ber

.in.the.dir

ection

.fro

.the.serv

.to.the.cli

ent

.(SY

N).

. e.Ack

nowledgment

.num

ber

.is.set.to.

the.cli

ent’s

.ISN.+.1.. e.serv

.ISN.is.set.to.a.ran

dom

.num

ber.

. e.opt

ion

.to.de

.cli

ent

.win

dow

siz

.mus

.also.be.sent

. 3.. In.rep

.to.the.seg

ment

.fro

.the.ser

ver,

.the.cli

ent

.sen

.as.seg

ment

.wit

.ACK.bit.set.and.the.

seg

ment

.num

ber

.set.to.its.ISN.+.1.. e.Ack

nowledgment

.num

ber

.is.set.to.the.ser

ver

.ISN.+.1.

. 4.. In.ver

.rar

.situ

ation,

.the.two.pro

cesses

.may.wan

.to.sta

.con

nection

.at.the.sam

.tim

.In.tha

cas

.bot

.wil

.iss

.an.act

ive

.ope

.seg

ment

.wit

.SYN.and.ISN

.and.the

.bot

.wou

.sen

.the.

ACK.seg

ment.

.A.situ

ation

.whe

.one.of.the.seg

ments

.is.los

.dur

ing

.the.tra

nsmission

.and.nee

.to.

be.re

sent

.a

.ti

me-out

.ma

.al

.be.an

alyzed.

61.2.4 Maintaining the Open Connection

Aer.connection.is.established,.each.process.can.send.data..Each.segment.has.its.sequence.number.

inc

reased

.by.the.numb

.of.byt

.sen

.in.the.pre

vious

.seg

ment,

.wit

.the.pre

vious

.seq

uence

.numb

er.

. e.

numb

.rol

.ove

.at.2

.. e.process.expects.to.receive.segments.with.ACK.bit.set.and.acknowledgment.

numb

ers

.tha

.con

rm

.tha

.dat

.are.rec

eived.

.Ack

nowledgment

.numb

.is.not.mer

ely

.the.rep

etition

of.the.rec

eived

.seq

uence

.numb

er.

.It.ind

icates

.the.nex

.exp

ected

.seq

uence

.numb

.of.a.seg

ment

.to.be.

rec

eived

.by.the.ack

nowledging

.pro

cess.

.Ack

nowledgments

.mus

.be.rec

eived

.wit

hin

.cer

tain

.tim

.fra

me,

not.eve

.seg

ment

.tha

.is.sen

.nee

.to.be.ack

nowledged.

.Sen

ding

.ack

nowledgment

.of.a.cer

tain

.seg

ment

.als

.ack

nowledges

.rec

eiving

.all.pre

vious

.seg

ments.

.Mor

.seg

ments

.are.usu

ally

.sen

.ahe

.bef

ore

the.sen

der

.exp

ects

.to.rec

eive

.an.ack

nowledgment.

.Sen

ding

.an.ack

nowledgment

.can.be.comb

ined

.wit

sen

ding

.da

.in.th

.ot

her

.di

rection

.(p

iggybacking).

61.2.5 Flow Control and Sliding Window Protocol

 e.amount.of.data.may.be.sent.before.waiting.for.an.acknowledgment.from.the.destination..In.extreme.

situ

ations,

.the.pro

cess

.may.wai

.for.an.ack

nowledgment

.for.eac

.seg

ment

.but.tha

.wou

.mak

.the.lon

dis

tance

.tra

nsmission

.ver

.slo

.due.to.lon

.lat

ency.

.On.the.oth

.han

.the.pro

cess

.may.sen

.all.dat

wit

hout

.wai

ting

.for.con

rmation.

. is.is.als

.imp

ractical

.bec

ause

.hig

.vol

ume

.of.dat

.may.nee

.to.be.

ret

ransmitted

.in.ca

.a.se

gment

.is.lo

.in.th

.mi

ddle

.of.th

.tr

ansmission.

Sliding

.win

dow

.pro

tocol

.is.a.sol

ution

.in-b

etween

.the.two.ext

reme

.situ

ations

.des

cribed

.abo

.tha

TCP.imp

lements

.in.ord

.to.spe

.up.the.tra

nsmission.

.TCP.sen

.as.muc

.dat

.as.all

owed

.by.a.so-

alled

.sli

ding

.win

dow

.bef

ore

.wai

ting

.for.an.ack

nowledgment.

.Ae

.rec

eiving

.an.ack

nowledgment,

.it.

mov

.(s

lides)

.th

.wi

ndow

.ah

ead

.in.th

.ou

tgoing

.da

.bu

er,

.as.il

lustrated

.in.Fi

gure

.61

.7.

.the.rec

eiving

.side

.inc

oming

.dat

.are.stor

.in.the.rec

eiving

.bu

.bef

ore

.dat

.are.con

sumed

by.the.com

municating

.pro

cess.

.Sin

.the.size.of.the.bu

.is.lim

ited,

.the.numb

.of.byt

.tha

.can.be.

rec

eived

.at.a.par

ticular

.tim

.is.lim

ited.

. e.size.of.the.unu

sed

.por

tion

.of.the.bu

.is.cal

led

.the.rec

eiver

window.

.In.ord

.to.mai

ntain

.the.ow.con

trol,

.the.sen

der

.mus

.be.pre

vented

.fro

.sen

ding

.the.exc

essive

Transmission Control Protocol—TCP 61-9

amount.of.data.and.overowing.the.incoming.data.buer.. is.is.implemented.by.controlling.the.

timing.when.the.acknowledgments.are.sent.

.the.receiving.process.consumes.data.at.a.faster.rate.than.they.arrive,.then.the.receiver.window.

expands.. is.information.is.passed.to.the.sender.as.an.option.included.in.a.segment.so.that.the.

sender.may.synchronize.the.size.if.its.sender window.. is.allows.more.data.to.be.sent.without.receiv-

ing

.an.acknowledgment..If.the.receiving.process.consumes.data.slower.than.they.arrive,.then.the.

receiver.buer.shrinks..In.that.case,.the.receiver.must.inform.the.sender.to.shrink.the.sender.window.

as.well.. is.causes.transmission.to.wait.for.more.frequent.acknowledgments.and.prevents.data.from.

being.sent.without.possibility.of.storing..If.the.receiving.buer.is.full,.then.the.receiver.may.close.

(set.to.zero).the.receiver.window.. e.sender.cannot.send.any.more.data.until.the.receiver.reopens.

the.window.

61.2.6 Improving Flow Control

In.case.when.one.or.both.communicating.processes.process.the.data.slowly,.then.a.problem.leading.to.

signicant.bandwidth.waste.may.arise..In.case.of.slow.transmission.caused.by.the.receiving.processes,.

the.sliding.window.may.be.reduced.even.as.low.as.to.1.byte..In.case.of.slow.transmission.caused.by.the.

sender,.data.may.be.sent.as.soon.as.it.is.produced.even.with.a.large.window,.one.byte.at.a.time,.as.well..

 is.causes.use.of.segments.that.carry.small.data.payload,.and.lowers.the.ration.of.carried.data.size.to.

the.total.segment.size,.and.to.the.total.packet.size.in.the.underlying.protocols..Extensive.overview.of.these.

and.other.problems.that.may.develop.is.provided.by.[RFC2525].and.[RFC2757]..Due.to.size.limitation.

of.this.article.only.two.most.commonly.known.problems.are.discussed.and.their.classic.solutions.are.

provided.here.

.prevent.this.situation,.data.should.not.be.sent.immediately.as.and.when.it.becomes.available,.but.

combined.in.larger.chunks,.provided.that.this.approach.is.suitable.for.a.particular.application..Nagle.

found.a.very.good.and.simple.solution.for.the.sender,.which.is.called.Nagle’s Algorithm.[RFC896].. e.

algorithm.can.be.described.by.the.following.three.steps:

•

. e.rst.piece.of.data.are.sent.immediately.even.if.it.is.only.1.byte.

•

. Aer.sending.the.rst.segment,.the.sender.waits.for.the.acknowledgment.segment.or.until.enough.

data.are.accumulated.to.ll.in.the.segment.of.the.maximum.segment.size,.whichever.happens.

rst.. en,.it.sends.the.next.segment.with.data.

•

. e.previous.step.is.repeated.until.the.end.of.transmission.

.the. receiving. side,. two. dierent.solutions.are.frequently. used.. Clark. proposed. to. send. the.

acknowledgment.as.soon.as.the.incoming.segment.arrives,.but.to.set.the.window.to.zero.if.the.receiv-

ing

.buer.is.full.(Figure.61.8b).[RFC813].. en,.to.increase.the.buer.only.aer.a.maximum.size.

of.a.segment.can.be.received.or.half.of.the.buer.becomes.empty.. e.other.solution.is.to.delay.the.

acknowledgment.and.thus.prevent.the.sender.from.sending.more.segments.with.data.. e.latter.of.

the.two.solutions.creates.less.network.trac.but.it.may.cause.unnecessary.retransmission.of.segment,.

if.the.delay.is.too.long.

Sliding window

1 2 3 4 5

Pointer

Bytes

can be sent

Bytes

cannot be sent

Bytes

have been sent

Acknowledged

bytes

6 7 8 9 10 11 12 13 14 15 16

FIGURE 61.7 Sender.buer.and.sliding.window.protocol.