eScience Lectures Notes : .

Slide 1 : 1 / 60 : Promises and Challenges of Networked Virtual Environments

Introduction to Networking over IP

Introduction

Slide 2 : 2 / 60 : Introduction to Networking with over IP

Introduction to Networking over IP

Main sources and reading : Chapter Three - A Networking Primer of "Networked Virtual Environments..." and Markus Buchhorn's presentation : "What will the New Internet Look Like"

Fundamental principles behind computer networking:

 

Slide 3 : 3 / 60 : Multicasting... the Network

A Network ...

Client, server, link, node, hub, switch, router ...

See another introduction to the Internet : http://escience.anu.edu.au/lecture/comp1710/internet/index.en.html

Slide 4 : 4 / 60 : Measures for Describing Network Behavior

Measures for Describing Network Behaviour

 

Slide 5 : 5 / 60 : Network Latency

Network Latency

Amount of time required to transfer a bit of data from one point to another

Delay of transfer

How up to date is the information

Reasons for network latency

Slide 6 : 6 / 60 : Network Bandwidth

Network Bandwidth

The rate at which the network can deliver data to the destination point

The amount of data that can be transmitted over a network in a fixed amount of time. Bandwidth is the fundamental networking parameter, and is usually measured in kilobits, megabits or gigabits per second (Kbps, Mbps, or Gbps).

Rate of transfer

Available bandwidth determined by wire and hardware

You may have High-Bandwidth and bad (high) latency (eg. Satellite)

A second of…

Or live streaming

9600bps = small email ~ 1,2 ko

56kbps = web graphic ~ 7ko

1Mbps = Document ~ 125 ko (cable, ADSL)

10Mbps = 1 floppy disk ~ 1,25 Mo (ethernet)

100Mbps = 2 MP3 songs ~ 12,25 Mo (ethernet)

1Gbps = 10m CD audio ~ 125 Mo (ethernet)

10Gbps = 2 CDs ~ 1,25 Go

100Gbps = 2 DVDs ~ 12,5 Go

56kbps = audio

300kbps = very useful video (cable, ADSL)

1500kbps, 2.2 Mbps= VHS video

6Mbps = PAL video

20Mbps = comp. HDTV

270Mbps = raw PAL video

1.5Gbps = raw HDTV

1Tbps = 50,000 channels of compressed HDTV

NB. : Mbps = 1000 x 1000 bit per second, kbps = 1000 bps, Gbps = 1000 Mbps   ..... minus overhead !

MB/s (Megabytes/s) : 1024x1024 bytes per second

The standard for carriers and networks is that Mbps is 1000x1000 bits per second (and Gigabit/s is 1000x1000x1000). That's also the transport rate, not the payload rate - so you need to allow for overheads of whatever protocols you are using. (e.g. tcp/ip/atm/sdh - you lose a lot of payload bandwidth that way.)
Conversely, if somebody quotes MB/s (Megabytes/s) they do usually mean 1024x1024 bytes per second.

Back in the bad old days, a 1 Megabyte floppy was 1024x1000 !

Slide 7 : 7 / 60 : Network Bandwidth (2)

Network Bandwidth (2)

See too : http://escience.anu.edu.au/lecture/comp1710/internet/evolution6.en.html

Slide 8 : 8 / 60 : AARNET : Existing research Network in australia

AARNET : Existing research Network in australia

Source : Markus Buchhorn's presentation : "What will the New Internet Look Like"

Slide 9 : 9 / 60 : AARNET : Backbone

AARNET : Backbone

Source : Markus Buchhorn's presentation : "What will the New Internet Look Like"

Slide 10 : 10 / 60 : AARNET : Local Peering

AARNET : Local Peering

Source : Markus Buchhorn's presentation : "What will the New Internet Look Like"

Slide 11 : 11 / 60 : AARNET : International Peering

AARNET : International Peering

Source : Markus Buchhorn's presentation : "What will the New Internet Look Like"

Slide 12 : 12 / 60 : AARNET : International Peering

The future : Grangenet and other research network / Americas

Source : Markus Buchhorn's presentation : "What will the New Internet Look Like"

Slide 13 : 13 / 60 : The futur : Grangenet and other research network / Asia-Pacific

The future : Grangenet and other research network / Asia-Pacific

Source : Markus Buchhorn's presentation : "What will the New Internet Look Like"

Slide 14 : 14 / 60 : The futur : Grangenet Backbone

The future : Grangenet Backbone

Source : Markus Buchhorn's presentation : "What will the New Internet Look Like"

Slide 15 : 15 / 60 : The future : Grangenet Bandwidth

The future : Grangenet Bandwidth

Source : Markus Buchhorn's presentation : "What will the New Internet Look Like"

Slide 16 : 16 / 60 : Internet 2 Internatioal

Internet 2 International

or when the gap between rich and poor countries keep growing ...

Source : http://www.internet2.edu/

Slide 17 : 17 / 60 : Network Reliability

Network Reliability

Measure of how much data is lost by the network during the journey

Two categories

Reliability can vary widely

When reliability needed, send acknowledgement

 

Slide 18 : 18 / 60 : Net Tools

Net Tools : How to observe the net

ifconfig : know your IP Number(s) and interface(s)

> ifconfig

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
tunnel inet -->
inet6 fe80::203:93ff:fe85:3724%en0 prefixlen 64 scopeid 0x4
ether 00:03:93:85:37:24
media: autoselect (10baseT/UTP <half-duplex>) status: active
supported media: none autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <half-duplex,hw-loopback> 10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback> 100baseTX <half-duplex> 100baseTX <half-duplex,hw-loopback> 100baseTX <full-duplex> 100baseTX <full-duplex,hw-loopback> 1000baseTX <full-duplex> 1000baseTX <full-duplex,hw-loopback> 1000baseTX <full-duplex,flow-control> 1000baseTX <full-duplex,flow-control,hw-loopback>
en1: flags=8822<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
tunnel inet -->
ether 00:30:65:1d:23:48
media: autoselect (<unknown type>) status: inactive
supported media: autoselect
ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1492
inet 203.221.196.72 --> 203.221.196.1 netmask 0xffffff00

 

Slide 19 : 19 / 60 : Net Tools

Net Tools : nslookup or dig : know an IP Number

> nslookup www.perthwa.com.au
Server: ns1.netspeed.com.au
Address: 203.31.48.7
Name: beast.aceonline.com.au
Address: 202.0.184.11
Aliases: www.perthwa.com.au, www.aceonline.com.au

> dig www.vuylsteker.net A

> dig www.vuylsteker.net M

 

Slide 20 : 20 / 60 : Net Tools

Net Tools : ping : know your return time

> ping www.perthwa.com.au
PING beast.aceonline.com.au (202.0.184.11): 56 data bytes
64 bytes from 202.0.184.11: icmp_seq=0 ttl=242 time=124.208 ms
64 bytes from 202.0.184.11: icmp_seq=1 ttl=242 time=109.093 ms
64 bytes from 202.0.184.11: icmp_seq=2 ttl=242 time=101.437 ms
64 bytes from 202.0.184.11: icmp_seq=3 ttl=242 time=123.74 ms
64 bytes from 202.0.184.11: icmp_seq=4 ttl=242 time=108.126 ms
64 bytes from 202.0.184.11: icmp_seq=5 ttl=242 time=104.234 ms
^C
--- beast.aceonline.com.au ping statistics ---
7 packets transmitted, 6 packets received, 14% packet loss
round-trip min/avg/max = 101.437/111.806/124.208 ms

 

Slide 21 : 21 / 60 : Net Tools : traceroute : know your way on the information highway

Net Tools : traceroute : know your way on the information highway

> traceroute www.perthzoo.wa.gov.au
traceroute to www.perthzoo.wa.gov.au (167.30.150.155), 30 hops max, 40 byte packets
1 transact-erx.netspeed.com.au (203.56.186.1) 17.026 ms 11.022 ms 21.744 ms
2 transact-bdr.netspeed.com.au (10.192.0.10) 18.132 ms 18.632 ms 25.001 ms
3 fastethernet2-0-8.cor1.can.connect.com.au (203.63.118.194) 22.521 ms 14.861 ms 21.535 ms
4 fastethernet6-0-0.bdr1.can.connect.com.au (203.63.113.62) 14.776 ms 15.219 ms 19.298 ms
5 atm9-1-0-5.bdr2.mel.connect.com.au (203.63.112.53) 98.269 ms 33.887 ms 34.314 ms
6 acc10930-10.gw.connect.com.au (203.8.183.254) 36.203 ms 30.106 ms 43.536 ms
7 431.at-6-0-0.xr2.mel1.alter.net (210.80.32.37) 107.133 ms 36.543 ms 31.474 ms
8 so-3-1-0.xr1.mel1.alter.net (210.80.32.1) 81.341 ms 38.143 ms 44.641 ms
9 so-0-0-0.xr1.cbr2.alter.net (210.80.33.26) 85.26 ms 52.434 ms 51.065 ms
10 so-3-1-1.xr2.cbr2.alter.net (210.80.33.146) 83.295 ms 50.417 ms 46.756 ms
11 so-0-0-1.xr1.syd2.alter.net (210.80.33.5) 79.57 ms 46.565 ms 60.311 ms
12 so-6-1-0.xr2.syd2.alter.net (210.80.33.138) 87.753 ms 48.755 ms 45.465 ms
13 so-0-0-0.xr2.per1.alter.net (210.80.33.30) 100.714 ms 95.259 ms 93.371 ms
14 412.atm8-0-0.gw1.per1.alter.net (210.80.32.114) 98.995 ms 102.387 ms 172.279 ms
15 cams-per1-gw.customer.alter.net (203.166.92.26) 94.057 ms 100.024 ms 95.546 ms
16 * * *
17 * * *

Slide 22 : 22 / 60 : Some graphical tool to look at the network : IPNetMonitorX

Some graphical tool to look at the network : IPNetMonitorX

Slide 23 : 23 / 60 : Network Protocol

Network Protocol

Describes the set of rules that two applications use to communicate to each other

Consists of three components:

Slide 24 : 24 / 60 : Packet Format

(Packet) Format 

->     ..............................
p      . Dest Add .. SrcAdd .. Type .
a      ..............................
c      . Title                      .
k      ..............................
e      . Description                .
t      .                            .
       .                            .
S      .                            .
i      .                            .
z      .                            .
e      .                            .
->     ..............................

Slide 25 : 25 / 60 : Packet Semantics

(Packet) Semantics

Sender and recipient must agree on what the recipient can assume if it receives a particular packet

What actions the recipient should take in response to the packet

May be described using a Finite State Machine (FSM) which represents the transitions involves in the protocol.

Ex. Mail session, using the SMTP Protocol (Simple Mail Transfert Protocol)

localhost.10:29.~ pvk > telnet cs.anu.edu.au 25
Trying 150.203.164.35...
Connected to cs.anu.edu.au.
Escape character is '^]'.
220 cs.anu.edu.au ESMTP Exim 3.35 #1 Mon, 05 Aug 2002 10:28:48 +1000
Helo ruth
250 cs.anu.edu.au Hello box.anu.edu.au [150.203.160.68]
Mail From:<GDAY@MATE.au>
250 <GDAY@MATE.au> is syntactically correct
Rcpt To:<pvk@vuylsteker.net>
250 <pvk@vuylsteker.net> is syntactically correct
Data
354 Enter message, ending with "." on a line by itself
Coucou PVK
How are you ?
.
250 OK id=17bVlN-0003b4-00
QUIT
221 cs.anu.edu.au closing connection
Connection closed by foreign host.


To learn more about SMTP protocol...

Slide 26 : 26 / 60 : Email header info

Original of that page : http://www.pop-cram-spam.net/SMTP.htm

What Some Of The Stuff In An Email Header Means

There are 5 SMTP (Simple Mail Transfer Protocol) commands used to send email via a SMTP mailserver. They are:

Helo
Mail From:
Rcpt To:
Data
Quit

Your average, everyday SMTP transaction (sending some email) would look like this:

[the Sender connects to the Mailserver]
Mailserver says: 220 mailserver.domain.com SMTP ... Greetings
    Sender says: Helo sender.host.name
Mailserver says: 250 Nice to meet you
    Sender says: Mail From:<sender@his.address>
Mailserver says: 250 Sender ok
    Sender says: Rcpt To:<recipient@his.address>
Mailserver says: 250 Recipient ok
    Sender says: Data
Mailserver says: 354 Enter mail, end with "." on a line by itself
    Sender says: Blah, blah, blah...            
    Sender says: <enter>.<enter>
Mailserver says: 250 Message accepted for delivery
    Sender says: Quit
and the SMTP transaction is complete, the email is on its way to the recipient.

A mailserver doesn't have to say "ok", it can say "Eat my shorts, spammer!" if it doesn't like anything the Sender has to say to it in any of the commands, but the open relays the spammers use to send their spam always say "ok".

Helo
The Helo is *supposed* to be the host name of the computer that has connected to the mailserver, but in the world of spam the Helo is just whatever the spammer feels like saying. Servers that are vulnerable to being relay-raped by spammers generally don't care what a spammer might say in the Helo. "Helo dust-bunny-gobbler" would generally be acceptable to a mailserver that is configured such that that it would allow spammers to relay-rape it. In fact, it would probably be acceptable to most mailservers running on the Internet. In general, the Helo can be anything the sender feels like saying.

Mail From:
This is *supposed* to be the email address of the sender, but similar to the Helo it is just what the sender *says*. Most mailservers will require the Mail From: to contain a valid domain name, but in the world of spam emanating from relay-raped servers, that isn't always the case. In any case the Mail From: is just what the sender *says*, and is totally unreliable.

Many mailservers create a Return-Path line when they recieve an email.. The email address in the Return-Path line is the email address entered with the Mail command. You may have seen references to the email "Envelope". The address entered with the Mail command is the "Envelope From" address. The "Envelope From" address is always there in the email from a mailserver point of view, but isn't always present in the received email. You won't see the "Envelope From" address unless a mailserver goes out of its way to present that address to you.

Rcpt To::
This is the email address of the recipient. This will always be valid. The email address entered here is the "Envelope To" address. The "Envelope To" address often doesn't appear anywhere in an email.

Data
This is where the message itself goes. Note that Received: lines generated by mailservers that have previously handled a message are passed along in the Data. Note also that header lines like To: and From: etc. are passed along in the Data, and that these lines can say anything the spammer wants them to say.

Sometimes a spammer doesn't include lines like To: and From: in his spam. Some mailservers don't like it that these header lines aren't present and will create them based on the "Envelope". Other mailservers don't care and will pass the email along with those lines absent. The positioning of lines like To:, From:, Date:, etc. are not good indicators of header forgery.

The most commonly used mailserver software on the Internet is Sendmail. Here's an example of the relevant part of a Sendmail Received: line.

Received: from [dial45.neoms.mail.us[245.15.75.158]] (kol-dial35.asysijd.cz
[195.75.66.68]) by mail.domain.com (8.8.7/8.8.7) with SMTP ..[snip]
The spammer said "Helo [dial45.neoms.mail.us[245.15.75.158]]". Sendmail reported the actual connecting IP address (195.75.66.68), and reported the rDNS lookup of 195.75.66.68 (kol-dial35.asysijd.cz). Other mailservers do things differently, from reporting *only* the Helo to reporting the connecting IP address and explicitly saying "Helo=[dial45.neoms.mail.us[245.15.75.158]]". That's the tricky bit to sorting out spam headers, knowing what a mailserver is actually telling you in its Received: line.

So, the Sendmail format looks like this: Received: from Helo (rDNS [IP.address]) by ....

Other formats are:
Received: from rDNS (Helo) (IP.address) by ....
Received: from rDNS by ....
Received: from IP.address by ....
Received: from [IP.address] by ....
Received: from Helo by ....
and more.

For an in depth header analysis tutorial check out http://www.stopspam.org/email/headers/headers.html

For more information on SMTP, see
http://www.faqs.org/rfcs/rfc821.html
and
http://www.faqs.org/rfcs/rfc822.html



Comments Welcome

Slide 27 : 27 / 60 : Error Behaviour

Error Behaviour

Rules about how each endpoint should respond to various error scenarios

What should I do if I don't receive an acknowledgement ?

What should the server do if the command that he has just received is not part of its official ones ? (=> send a list of available command for instance)

Same as previously : the error conditions are typically described within the same FSM that describes the normal protocol semantics

Slide 28 : 28 / 60 : Layer

Layers of protocols, TCP/IP example

TCP/IP is made up of two acronyms, TCP, for Transmission Control Protocol, and IP, for Internet Protocol. TCP handles packet flow between systems and IP handles the routing of packets. However, that is a simplistic answer that we will expound on further.

All modern networks are now designed using a layered approach. Each layer presents a predefined interface to the layer above it. By doing so, a modular design can be developed so as to minimise problems in the development of new applications or in adding new interfaces.

The ISO/OSI protocol with seven layers is the usual reference model. Since TCP/IP was designed before the ISO model was developed it has four layers; however the differences between the two are mostly minor. Below, is a comparison of the TCP/IP and OSI protocol stacks:

 

OSI Protocol Stack 
   7. Application   -- End user services such as email.
   6. Presentation  -- Data problems and data compression
   5. Session       -- Authentication and authorisation
   4. Transport     -- Guarantees end-to-end delivery of packets
   3. Network       -- Packet routing
   2. Data Link     -- Transmit and receive packets
   1. Physical      -- The cable or physical connection itself.
TCP/IP Protocol Stack. 
   5. Application   -- Authentication, compression, and end user services.
   4. Transport     -- Handles the flow of data between systems and 
                       provides access to the network for applications via
                       the (BSD socket library)
   3. Network       -- Packet  routing
   2. Link          -- Kernel OS/device driver interface to the network 
                       interface on the computer.

Major difference between the OSI and TCP/IP:

Software Components of TCP/IP

Application Layer
Some of the applications we will cover are SMTP (mail), Telnet, FTP, Rlogin, NFS, NIS, and LPD
Transport Layer
The transport uses two protocols, UDP and TCP. UDP which stands for User Datagram Protocol does not guarantee packet delivery and applications which use this must provide their own means of verifying delivery. TCP does guarantee delivery of packets to the applications which use it.
Network Layer
The network layer is concerned with packet routing and used low level protocols such as ICMP, IP, and IGMP. In addition, routing protocols such as RIP, OSPF, and EGP will be discussed.
Link Layer
The link layer is concerned with the actual transmittal of packets as well as IP to ethernet address translation. This layer is concerned with Arp, the device driver, and Rarp.

To know more about TCP/IP...

Slide 29 : 29 / 60 : Introduction to TCP/IP Networking

Introduction to TCP/IP Networking

Source of the information : http://userpages.umbc.edu/~jack/ifsm498d/tcpip-intro.html

Historical Overview

The strength of Unix is the built-in networking provided under Unix. In the early 1980s, the Universiy of California at Berkeley (Berkeley), had taken the original System 7 version of Unix developed at AT&T and made substantial modifications to that version of Unix. Key additions, were support for virtual memory and the initial release of TCP/IP for Unix. This release from Berkeley was known as 4.2 BSD. In 1986, Berkeley released a new version of Unix, BSD 4.3, with substantial improvements to the TCP/IP networking code.

Whether a system uses a System V or a BSD based kernel all versions of Unix now ship with 4.3 BSD networking software. Since this software was developed at Berkeley, under a US government grant, it has been available to any vendor or university at minimal cost. The TCP/IP code developed at Berkely has been ported to other operating systems, such as the DEC VMS , Macintsh, DOS, Windows, IBM CMS, IBM MVS, andmany other systems.Due to the ubiquity in the platforms where TCP/IP is available it has become the primary means for interconnecting systems in a heterogeneous computing environment.

Unix has been the platform for TCP/IP development. While Berkeley has been the main contributor countless others have contributed to the effort. This work has produced a system for networking that has proven itself over the years. Presently, there are estimated to be over 5 million systems running the TCP/IP software suite, the overwhelming majority are microcomputers. Unix has evolved as the platform to use for integrating these many different systems into something useful. As a system administrator on a Unix system it is very likely you will be involved in networking issues and need to have a basic understanding of things work.

Many vendors have provided other network on Unix systems other than (or in addition too) TCP/IP. DEC has offered a version of it's DECNET software for systems running it's version of Unix, named Ultrix. IBM also offers a version of their propreitary SNA network software on IBM AIX machines. However, the emphasis in this course will be on the TCP/IP

Introduction to TCP/IP

TCP/IP is made up of two acronyms, TCP, for Transmission Control Protocol, and IP, for Internet Protocol. TCP handles packet flow between systems and IP handles the routing of packets. However, that is a simplistic answer that we will expound on further.

All modern networks are now designed using a layered approach. Each layer presents a predefined interface to the layer above it. By doing so, a modular design can be developed so as to minimize problems in the development of new applications or in adding new interfaces.

The ISO/OSI protocol with seven layers is the usual reference model. SInce TCP/IP was designed before the ISO model was developed it has four layers; however the differences between the two are mostly minor. Below, is a comparison of the TCP/IP and OSI protocol stacks: 

             OSI Protocol Stack

   7. Application   -- End user services such as email.
   6. Presentation  -- Data problems and data compression
   5. Session       -- Authenication and authorization
   4. Transport     -- Gaurentee end-to-end delivery of packets
   3. Network       -- Packet routing
   2. Data Link     -- Transmit and receive packets
   1. Physical      -- The cable or physical connection itself.

            TCP/IP Protocol Stack.

   5. Application   -- Authenication, compression, and end user services.
   4. Transport     -- Handles the flow of data between systems and 
                       provides access to the network for applications via
                       the (BSD socket library)
   3. Network       -- Packet  routing
   2. Link          -- Kernel OS/device driver interface to the network 
                       interface on the computer.
Below are the major difference between the OSI and TCP/IP:

Software Componets of TCP/IP

Application Layer
Some of the applications we will cover are SMTP (mail), Telnet, FTP, Rlogin, NFS, NIS, and LPD
Transport Layer
The transport uses two protocols, UDP and TCP. UDP which stands for User Datagram Protocol does not gaurentee packet delivery and applications which use this must provide their own means of verifying delivery. TCP does gaurentee delivery of packets to the applications which use it.
Network Layer
The network layer is concerned with packet routing and used low level protocols such as ICMP, IP, and IGMP. In addition, routing protocols such as RIP, OSPF, and EGP will be discussed.
Link Layer
The link layer is concerned with the actual transmittal of packets as well as IP to ethernet address translation. This layer is concerned with Arp, the device driver, and Rarp.

Over the next few months we will be examining these components as we work our way up from the bottom. First, we need to get a basic upderstanding of how networks are designed and how the basic hardware used to interconnect them.

Basic Network Design

The most common form of network is Ethernet. This is a bus-like network that uses Carrier-Sense Multiple Access with Collision Detection (CMSA-CD). Interpreting this we have a network where stations apply a voltage to the bus when they wish to send data, by sensng the bus for this voltage we can determine if the bus is in use; multiple access implies many hosts may be on this bus; collision detect is used to detect multiple hosts sending data at the same time. Initially, it would seem unnecessary to need collision detection, after all, a station on sends data on the bus when there is no one else sending. Due to the propagation delay of electrical signals we can have to stations decide to send data at the same time, when each station looks at the bus it is clear, however before the data they send reaches it's destination they will collide and the result will be garbage. The collision detection circuitry monitors the line to verify there were no collisions and the data does not need to be resent.

Understanding the CMSA-CD concept is fundamental to understanding how ethernet works. All limitations found on the design of ethernet networks are there do to issues surrounding CMSA-CD. The biggest design limitation is that reading data on an ethernet is a passive operation, the sending stations has no way to "sense" when this has happened. However, the sending station must perform collision detection until it knows the receiving station has gotten the packet! To do, lenght restrictions must be developed so that a sending station knows that within a finite time the receiving stations must have gotten the packet. This time limit controls most aspects of network design.

A basic way of calculating this time limit is to look at how long a machine must monitor the network is to look at the underlying physics. By it's definition ethernet operates at a speed of 10 Mhz (10 million bits/sec). The maximum packet size is 1500 bytes (12,000 bits). Presently ethernet has a maximum lenght of 500 meters. The time required to transmit 1500 bytes over 500 meters is:

Time to transmit a packet is 12000 bits/10,000,000 bits/sec is .0012 seconds

Time to transmit a bit 500 meters is defined by the speed that electrical signals travel, which is the speed of light. This figure turns out to be :

500 meters / 60000 meters/sec which equaks .0008333 seconds

Other characteristics that define ethernet deal with the waveform that a ethernet signal assumes. The waveform on a thick ethernet segment is 2.5 meters in lenght, that is why stations are seperated by 2.5 meters. Ethernet Hardware Ethernet has evolved over time. Ethernet version 2 released in 1982 was originally developed by Xerox-Intel-Dec. In 1985 the IEEE released a new standard for ethernet. This standard is named IEEE 802.2. In general, these two versions of ethernet can inter-operate, however there are a few minor differences. The first difference is that in the ethernet packet header Version 2 defined a two byte Type field while IEEE created a 2 byte length field in that location. Luckily, values for type cannot conflict with valid length values and most systems can determine the Ethernet Frame type by examining this field. A second difference was that the Ethernet version 2 spec required that a transciever send a heartbeat signal each second. The IEEE 802.2 spec removed this. This has resulted in most vendors offerring transcievers that have a switch to enable or disable hearbeat. It should be off unless connected to a piece of equipment using the ethernet version 2 spec. Luckily, all new devices are built to conform to the 802.2 spec; however there are occasionally devices found that were installed years ago that still need this.

In either specification, ethernet uses a 48 bit identifier to uniquely identify each source and destination device. A range of addresses is assigned to each manufactuer of ethernet equipment.

There are basically two categories of ethernet components, one type that passes the signal onto other devices, generally these are known as repeaters. A secondtype of device which takes the signal and regenerates the signal onto a new network, these types of devices are generally known as bridges or routers. Repeaters are useful for propagating a network signal, a signal comes in on an input port is often output to many ports.However since they add some delay to the transmittal of packets they reduce the maximum size a segment can be. However, repeaters can simplify the design of a network.

Devices such as bridges and routers, which regenerate the signal, allow you to build larger networks. Since the signal is regenerated, it becomes the responsibility of the bridge or router to gaurentee the packets arrival at the destination (or the next router or bridge). Bridges and routers work at different levels of the network. Bridges work at the ethernet frame level while routers work at the protocol level. In both cases, the bridge or router, has the property of filtering traffic and only transmitting the signal onto networks where it makes sense. Thus, in each case they have the effect of reducing unnecessary traffic.

Types of Media used with Ethernet

The IEEE 802.2 spec defines the general properties of ethernet. Subsuquent standards define how each media type will operate. At present, ethernet can be run over voice grade twisted pair (10BASE-T), thinwire coaxial cable (10Base-2), thickwire coaxial cable (10Base-5), and fiber optic cable (10Base-F). The overwhelming majority of connections made today use twisted-pair wiring. This option is now offered as standard equipment on many workstation models.

Each media type has different signal properties and limits. For example, (10BASE-T) only supports one machine per segment and is limited in distance to 100 meters. Thinwire (10BASE-2) can support up to 29 stations and is limited to a maximum distance of 185 meters. Fiber optic cabling can support 1024 devices and can operate at distances up to 2 Kilometers. Thickcoaxial cable (10BASE-5) can operate up to 500 meters and support up to 1024 stations.

Trancievers often allow you to attach dis-similar devices togethor. Many machines have a 15 pin Ethernet AUI interface. Tranceivers exist which allow you to adapt the AUI interface to whatever media you have running to the desktop.

Designing Ethernet Networks

The goal in designing networks is to maximize reliability while minimizing cost. These are usually conflicting goals and tradeoffs must be made. In our environment we try to follow these guidelines: Before designing networks make sure you understand and follow the design limitations for each media type you use. The ethernet standard is conservative by nature and often things will work if you violate the design limitations; however when you violate the standard you often will see intermittent problems that are very difficult to diagnose. For that reason it is Stongly recommended you adhere to the standards.

Slide 30 : 30 / 60 : The BSD Sockets Architecture

The BSD Sockets Architecture

Thousands of network protocols (at different layer level)

When an application sends a packet, the host must make sure that it gets sent to the right destination, and when a host receives a packet, it must make sure that it is delivered to the correct application. To achieve these two tasks, most hosts on the Internet use the Berkeley Software Distribution (BSD) Sockets network architecture to keep track of applications and network connections.

This architecture first gained wide acceptance in the Unix operating system, but today, it is implemented on virtually all of the major commercial operating systems on the market. The WinSock library used on Microsoft Windows 3.1/95/NT platforms is a derivative of the BSD interfaces [Quinn/Shute95].

Slide 31 : 31 / 60 : Sockets and Ports

Sockets and Ports

Socket: a software representation of the endpoint of a communication channel

Port: A specific numerical identifier for an individual application

Slide 32 : 32 / 60 : Sockets

Sockets

A socket identifies several pieces of information about a communication channel:

Example of the URL : protocol://Destination.host:destinationPort/

Slide 33 : 33 / 60 : Port Numbers

Port Numbers

Provide foundation of open networking

Like a set of post office box numbers for the protocol

Each type of application gets a port number

Port number + host address gives it a unique identifier to send and receive

Over 65,000 valid port numbers

OS can support many applications at once

Warcraft : What ports need to be open?

In order to connect to Battle.net, connect to others over a Local Area Network, and allow others to connect to games you create, the following ports need to be opened.
Diablo, Warcraft II Battle.net Edition, and StarCraft:
* Ports 6112 through 6119 TCP & UDP

Slide 34 : 34 / 60 : Port Number Allocation

Port Number Allocation

Port numbers 1 - 1023 are reserved for “well-known” applications/OS services

1024 - 10,000 are registered for certain “well-known” protocols

Example:

See the IANA : RFC 1700 or http://www.isi.edu/in-notes/rfc1700.txt

NB. : What is a Request For Comment ?

How IP has been built, Released by the Internet Architecture Board (IAB)

Slide 35 : 35 / 60 : Internet Protocols for Networked Virtual Environments

Internet Protocols for Networked Virtual Environments

Common Internet Protocols

Slide 36 : 36 / 60 : The Internet Protocol

The Internet Protocol

Low-level protocol used by hosts and routers to ensure the packets travel from the source to the destination

Includes facilities for splitting the packets into small fragments

Also includes time to live (TTL) field

Slide 37 : 37 / 60 : TCP : Transmission Control Protocol

TCP : Transmission Control Protocol

Slide 38 : 38 / 60 : UDP : User Datagram Protocol

UDP : User Datagram Protocol

The User Datagram Protocol (UDP) is a lightweight communication protocol

Differs from TCP in three respects:

Does not establish peer-to-peer connections

Slide 39 : 39 / 60 : UDP : User Datagram Protocol (2)

UDP : User Datagram Protocol (2)

Sender and recipient of do not keep any information about the state of the communication session between the two hosts

Simply provides best-efforts delivery

No guarantee that data is delivered reliably or in order

Endpoints do not maintain state information about the communication,

UDP data is sent and received on a packet-by-packet basis

Datagrams must not be too big, because if they must be fragmented, some pieces might get lost in transit

Slide 40 : 40 / 60 : UDP advantages

UDP advantages

Simplicity ...

for the network, not the programmer

Does not include the overhead needed to detect reliability and maintain connection-oriented semantics

UDP packets require considerably less processing at the transmitting and receiving hosts

Does not maintain the illusion of a data stream

packets can be transmitted as soon as they are sent by the application instead of waiting in line behind other data in the stream; similarly, data can be delivered to the application as soon as it arrives at the receiving host instead of waiting in line behind missing data

Less heavy to manage for the OS

Many operating systems impose limits on how many simultaneous TCP/IP connections they can support.

Operating system does not need to keep UDP connection information for every peer host, UDP/IP is more appropriate for large-scale distributed systems where each host communicates with many destinations simultaneously

Slide 41 : 41 / 60 : UDP disadvantages

UDP disadvantages

Lots of possible intrusions

When a socket is receiving data on a UDP port, it will receive packets sent to it by any host, whether it is participating in the application or not

This possibility can present a security problem for some applications that do not robustly distinguish between expected and unexpected packets

Blocking of UDP by your local net administrator

For this reason, many network firewall administrators block UDP data from being sent to a protected host from outside the security perimeter

Slide 42 : 42 / 60 : How to Broadcast Information ?

How to Broadcast Information ?

With UDP/IP, an application can direct a packet to be sent to one other application endpoint

Could send the same packet to multiple destinations by repeatedly calling sendto() (in C) or DatagramSocket.send() (in Java)

This approach has two disadvantages:

Slide 43 : 43 / 60 : UDP Broadcasting

UDP Broadcasting

UDP broadcasting provides a partial solution to these issues

Allows a single transmission to be delivered to all applications on a network who are receiving on a particular port

Useful for small net-VE’s

Expensive

every host on network must receive and process every broadcast packet

Not used for large or internet based VE’s (use IP Multicast)

Again subject to the usual suspicion from your local network administrator

No way to use it over the public internet

Use of a bit mask representing the subnet of hosts that should receive that message : control of the scope or range of the broadcast.

For instance, to broadcast only on the escience lab network (150.203.164.*), one should use the mask 150.203.164.255

Slide 44 : 44 / 60 : Multicasting... the Network

Multicasting... the Network

Slide 45 : 45 / 60 : Multicasting... Unicasting

... Unicasting ...

Slide 46 : 46 / 60 : Multicasting... Broadcasting

... Broadcasting ...

Slide 47 : 47 / 60 : Multicasting... !!!

... Multicasting !!!

Slide 48 : 48 / 60 : IP Multicasting

IP Multicasting

UDP broadcasting can only be used in a LAN environment

Even if no application on that host is actually interested in receiving the packet each host on the LAN must:

Multicasting is the solution to both of these concerns

Comparaison to real world news system

 

Slide 49 : 49 / 60 : IP Multicasting (2)

IP Multicasting (2)

IP addresses in the range 224.0.0.0 through 239.255.255.255 are designated as multicast addresses

The sender transmits data to a multicast IP address, and a subscriber receives the packet if it has explicitly joined that address

Each Multicast IP address is connected to a multicast distribution tree built by the network

To chose a free Multicast address...

Slide 50 : 50 / 60 : IP Multicasting (3)

IP Multicasting (3)

Rapidly emerging as the recommended way to build large-scale net-VEs over the Internet

Provides:

Using a well-known multicast address, net-VE participants can announce their presence and learn about the presence of other participants

Also an appropriate technique for discovering the availability of other net-VE resources such as terrain servers
These features make multicasting desirable even for LAN-based net-VEs.

Slide 51 : 51 / 60 : IP Multicasting : Limitations

IP Multicasting : Limitations

Limitations generally related to its infancy

Although an increasing number of routers are multicast-capable, many older routers are still not capable of handling multicast subscriptions

In the meantime, multicast-aware routers communicate directly with each other, “tunneling” data past the routers that cannot handle multicast data

Multicast on a LAN : Still Broadcasting when it comes to the bandwidth use

Slide 52 : 52 / 60 : Comparaison of the network protocol alternnatives

Comparison of the network protocol alternatives

Because most of the time, design of NVE is more about choosing which protocol for which data...

Protocol Strengths Limitations Net-VE characteristics

TCP

Guaranteed packet delivery

Ordered Packet Delivery

Packet checksum checking

Transmission flow control

Ubiquitous, with many firewalls supporting outbound connections

Only supports points to points connectivity

Bandwidth overhead

Packet may be delayed to preserve ordering guarantees

Virtual environments having relatively small number of hosts and limited data requirements

Typically used in client-server configuration, and over public Internet

Relatively easy for the programmers

 

UDP

Packet-based data transmission

Low overhead

Immediate delivery

Nearly Ubiquitous, but firewalls are often problematic

Only supports point to point connectivity

No reliability guarantees

No ordering guarantees

Packet corruption possible

Virtual environments having higher data requirements; used in both client-server and peer to peer configurations

IP Broadcasting

Same as UDP, except simultaneous delivery to multiple hosts

Same as UDP,except scope limited to local networks

Small-scale peer to peer net-VEs with high data requirements and time sensitive data delivery needs

IP Multicasting

Same as IP Broadcasting except efficient Internet-wide delivery

Same as UDP, except only available from / to Internet hosts connected to the MBone

Large Scale peer to peer and client server net-VEs, particularly over the Internet

Slide 53 : 53 / 60 : Comparaison of the network protocol alternnatives

Comparison of the network protocol alternatives (2)

Use UDP... and then chose what you want get from TCP and implement it...

But not more than one or two options, or then come back to TCP/IP !

Issue in broadcasting and Multicasting... mix of packet with other application

Slide 54 : 54 / 60 : JAVA TCP/IP Socket Implementation

JAVA TCP/IP Socket Implementation

Client Actions

Server Actions
  1. Instantiate a Socket object
  2. Communicate with server
    1. Send data/requests
    2. Receive data/replys
  3. Close the socket
  1. Instantiate a ServerSocket object
  2. Receive connections from clients
  3. Communicate with clients
    1. Recieve data/requests
    2. Send data/replys
  4. Close the socket

Slide 55 : 55 / 60 : JAVA TCP/IP Socket Implementation (2)

JAVA TCP/IP Socket Implementation (2)

Client Actions

INSTANTIATE SOCKET OBJECT
  1. Instantiate a Socket object
  2. Communicate with server
    1. Send data/requests
    2. Receive data/replys
  3. Close the socket

Instantiating a socket creates a socket and connects it to the server

Two common constructors

  • arguments are host name and port number
  • arguments are host IP address and port number
 
import java.net.Socket;
import java.io.IOException;
import java.io.DataInputStream;
import java.io.DataOutputStream;


Socket sock;	// Declare the socket
				// Instantiate the socket using host name and port number
try {
	sock = new Socket("ephebe.anu.edu.au", 13214);
	//	or...Retrieve the host’s internet address ...
	//	InetAddress addr = InetAddress.getByName("150.203.164.3");
	//	sock = new Socket(addr, 13214);}
catch(IOException ioe) {
	System.out.println("Error opening socket: " + ioe.getMessage());
	return;
}

Slide 56 : 56 / 60 : JAVA TCP/IP Socket Implementation

JAVA TCP/IP Socket Implementation (3)

Client Actions

Communicate with server

  1. Instantiate a Socket object
  2. Communicate with server
    1. Send data/requests
    2. Receive data/replys
  3. Close the socket
  • Data is exchanged by reading and writing to input and output streams
  • Create a DataOutputStream
  • When creating the DataOutputStream tie it directly to the socket
  • Writing to the DataOutputStream then causes the data to automatically be transmitted to the server
 
try{
		//  Instantiate an output stream tied directly to the socket
	DataOutputStream oStream = new DataOutputStream(sock.getOutputStream());
		//  write a string and an int to the output stream, 
		//	i.e. transmit them to the server
	oStream.writeUTF("Hello!");
	oStream.writeInt(3);
	oStream.flush(); //tell java to empty the stream right now (= send the information)
}
catch(IOException ioe) {
	System.out.println("Write error: " + ioe.getMessage());
}

Slide 57 : 57 / 60 : JAVA TCP/IP Socket Implementation

JAVA TCP/IP Socket Implementation (4)

Client Actions

Close the socket
  1. Instantiate a Socket object
  2. Communicate with server
    1. Send data/requests
    2. Receive data/replys
  3. Close the socket
  • Close the socket when finished communicating
  • Both client and server must close their sockets to completely tear down the connection
  • Server must also close down the ServerSocket when no more client connections are expected
 
try	{
	sock.close();
}
catch(IOException ioe) {
	System.out.println("Close error: " + ioe.getMessage());
}

// Again, close() needs to be called on both sides of the connection, and the server should 
// also be sure to close() the ServerSocket when it no longer wishes to accept client
// connections.

Slide 58 : 58 / 60 : JAVA TCP/IP Socket Implementation

JAVA TCP/IP Socket Implementation (5)

Server Actions

Instantiate a ServerSocket object
  1. Instantiate a ServerSocket object
  2. Receive connections from clients
  3. Communicate with clients
    1. Recieve data/requests
    2. Send data/replys
  4. Close the socket
  • Instantiating a ServerSocket object creates a socket ready to accept client connections
  • Replaces the socket(), listen(), and
    bind() functions in C / C++
  • Three common constructors, arguments are...
  1. port number
  2. port number, listener backlog
  3. port number, listener backlog and IP address 
import java.net.ServerSocket;
import java.net.Socket;
import java.io.IOException;
import java.io.DataInputStream;
import java.io.DataOutputStream;

ServerSocket acceptSock;                   // Declare the ServerSocket

//  Instantiate a ServerSocket using constructor that takes only the port number
try {
	acceptSock = new ServerSocket(13214);
}

catch(IOException ioe) {
	System.out.println("Error opening server socket: " + ioe.getMessage());
	return;
}

Slide 59 : 59 / 60 : JAVA TCP/IP Socket Implementation (6)

JAVA TCP/IP Socket Implementation (6)

Server Actions

Receive connections from clients
  1. Instantiate a ServerSocket object
  2. Receive connections from clients
  3. Communicate with clients
    1. Recieve data/requests
    2. Send data/replys
  4. Close the socket
  • Accept() call returns a socket that is the connection to a specific client
  • JAVA blocks on the accept() call
  • Usual practice is to fork a thread for each client as well as one for the socket designated to recieve client connections
 
Socket sock;	// Declare a socket to represent the connection to a
				// specific client, i.e. the socket client and server will
				// communicate over

//  Call accept() on the ServerSocket to receive client connections,
//  when a connection is received a new socket is returned over which
//  the client and server will communicate

while(true) {
	try {
		sock = acceptSock.accept();
	}
	catch(IOException ioe) {
 		System.out.println("accept error: " + ioe.getMessage());
		break;                    
 	}
	/* ... Process client connection ... */
}
// Only break out of while loop if there was an error

Slide 60 : 60 / 60 : JAVA TCP/IP Socket Implementation (7)

JAVA TCP/IP Socket Implementation (7)

For More see Sun Web site : http://java.sun.com/docs/books/tutorial/networking/index.html

Server Actions

Communicate with clients
  1. Instantiate a ServerSocket object
  2. Receive connections from clients
  3. Communicate with clients
    1. Recieve data/requests
    2. Send data/replys
  4. Close the socket
  • Data is exchanged by reading and writing to input and output streams
  • Create a DataInputStream
  • When creating the DataInputStream tie it directly to the socket 
try{
	//  Instantiate an input stream tied directly to the socket
	DataInputStream iStream = new DataInputStream(sock.getInputStream());
      
	//  Read a string and an int from the input stream, i.e from the socket
	//  You need to know the Semantics of the used protocol !
	String helloString = iStream.readUTF();
	int three = iStream.readInt();
}
catch(IOException ioe) {
	System.out.println("Read error: " + ioe.getMessage());
}

try{
    sock.close();
}	
catch(IOException ioe) {
	System.out.println("Close error: " + ioe.getMessage());
}