eheu..reden, sekedar info..multicast itu juga sebenernya broadcast loh 

jadi multicast itu pada dasarnya broadcast jika server berada di satu network (subnet)..jadi misal nih kita bikin server di subnet 200 dan kita kirim data secara multicast, maka semua host yang ada di subnet 200 bakalan nerima tu data

yang membedakan disini, diantaranya :

1. kemampuan paket untuk melintas melewati sebuah router, ingat..secara default, router akan melakukan drop paket broadcast..kenapa? nah klo ini mendingan baca lagi konsep layering di TCP/IP

2. menggunakan alamat IP kelas D yaitu 224.0.0.0/4, jangan diartikan server harus di set pada alamat tersebut lho yak..tapi sebenernya konsep multicast ini sedikit aneh..tar di jelasin di bawah aja

3. pengirim hanya akan mengirimkan satu stream data saja untuk banyak client sekaligus, sedangkan router bertugas menggandakan data tersebut untuk beberapa client dibawahnya yang tergabung dalam alamat multicast.

Nah skarang masalah IP kelas D, misal server ada di subnet 200, server menggunakan IP address 10.14.200.31, dia akan mengirimkan data secara multicast maka pada server tinggal di set kirimkan data ini ke alamat multicast 224.10.10.10. Dari situ, nantinya semua client yang menginginkan data tersebut harus menggabungkan diri ke alamat tersebut. Caranya? eheu...ya byasa aja sih, kalo dalam hal ini kasusnya stream audio ya di winamp tinggal di play udp:@224.10.10.10 (misalnya).

Apakah hal ini efektif? jawabannya iya untuk hubungan antar subnet, tapi efeknya? yaph..banjir data di subnet yang sama dengan pengirim...

Untuk lebih lengkapnya bisa dilihat dari artikel2 tentang multicast..trus sebagai catetan..router yang dapat melewatkan paket multicast juga khusus, byasanya disebut multicast enable router...

PS : itu keknya gw tau siapa biang keladi tugas besar itu..ehe, jangan keburu serem..sebenernya yang dibuat sebelumnya itu cuman broadcast (dia pake judul multicast tapi dilakukan dalam satu subnet)

Biasanya pada NS - 2 telah disediakan paket graph untuk memunculkan dan menganalisa grafik suatu script tr . Biasanya sih make xgraph yang udah ada di dalam folder ns-allinone . Cara nompile sgraph cukup gampang , yaitu :

1. Masuk ke folder xgraph .
    #cd xgraph (tergantung seri foldernya)
    #ls
setelah listnya ditampilkan, maka akan muncul file "install" . file inilah yang digunakan untuk menginstal si xgraph .
2. karena file instal belum bisa dieksekusi, maka kita ubah dulu bentuknya
    #sudo make
    #sudo make install
setelah filenya berubah (berwarna hijau), file tinggal di-run
    #./install
3. Maka file tersebut akan menginstal si xgraph . Nah habis itu di configure
    #./configure
4. Udah deh, perhatiin ada bug / eror ngga . kalo ngga, berarti xgraph bisa dijalankan.
    #xgraph aduhguepusingbanget.tr
ntar muncul deh grafik yg sesuai dengan parameter yg kita buat di file tcl

 

Naah kita tinggal menganalisa grafik2 ini . 

tapi kadang pada OS atau NS tertentu, xgraphnya ga support atau ga mau di run . Naah itu dia yg bikin kesel. Sebenarnya kalo mau ngoprek NS, kita bagusnya make Slackware, karna si Slackware ini udah support banget ama ns. Jarang banget ada bug2 ato erornya.
Kebetulan gw make ubuntu yg cukup punya banyak mslh dengan si NS-2 ini . Kemaren tuh mau nge-trace. Tapi ternyata Xgraphnya ga mau dieksekusi. Menurut saran senior, kita harus nginstal tracegraph yang lain, yaitu tr-graph . Tapi berhubung gw belum nemu sourcenya, tr-graph ini akan gue gelasin ntar aja.

Eeeh, ketinggalan. Gw baru dapet solusi xgraph yang kemarin. ternyata si xgraph ini cuma bisa dipake buat ngetrace file .tr yg dihasilkan oleh delay.awk . jadi si xgraph cuma dipake buat ngetrace delay . katanya kalo mau ngetrace yg lain kudu nambahin patch lagi (tapi gw jg blm ngerti).

sekiaan :D

set ns [new Simulator]
set nf [open out.nam w]

$ns namtrace-all $nf

proc finish {} {
    global ns nf
    $ns flush-trace
    close $nf
    exec nam out.nam &
    exit 0
}

set n0 [$ns node]
set n1 [$ns node]
set n2 [$ns node]
set n3 [$ns node]


$ns duplex-link $n0 $n2 1Mb 10ms DropTail
$ns duplex-link $n1 $n2 1Mb 10ms DropTail
$ns duplex-link $n3 $n2 1Mb 10ms DropTail

set tcp0 [new Agent/TCP]
$ns attach-agent $n0 $tcp0
set udp0 [new Agent/UDP]
$ns attach-agent $n1 $udp0

set sink0 [new Agent/TCPSink]
$ns attach-agent $n3 $sink0
set null0 [new Agent/Null]
$ns attach-agent $n3 $null0

$udp0 set class_ 1
$tcp0 set class_ 2
$ns color 1 Blue
$ns color 2 Red
$ns connect $udp0 $null0
$ns connect $tcp0 $sink0

set ftp0 [new Application/FTP]
$ftp0 attach-agent $tcp0

set cbr0 [new Application/Traffic/CBR]
$cbr0 attach-agent $udp0

$ns at 0.5 "$cbr0 start"
$ns at 4.5 "$cbr0 stop"
$ns at 0.5 "$ftp0 start"
$ns at 4.5 "$ftp0 stop"

$ns at 5.0 "finish"

$ns run

Simulation results in [GM:sigmetrics02] and [GM:spie02] were all performed in ns-2.

Size-aware scheduling consists of two parts: packet classification and packet differentiation. Therefore, corresponding modules (size-aware classifier and corresponding AQM schemes like RIO-PS) need to be installed. Step-by-step instructions can be found here.

When all the modules have been installed, we now see an illustrative scenario in which flows of size 5 packets or below being identified as short flows, and enjoy high priorities in packet delivery.  Figure 1 depicts the simulation topology.


Figure 1: Simulation Topology


In this simple example, there are two parallel TCP sessions sharing a single bottleneck link between
node 1 and node 2 (of capacity 700kb).

# Create a dumbbell topology $ns duplex-link $s(0) $n(0) 1Mb 5ms DropTail $ns duplex-link $s(1) $n(0) 1Mb 5ms DropTail $ns duplex-link $n(0) $n(1) 1Mb 20ms RED/myRIO $ns duplex-link $n(1) $n(2) 700Kb 25ms RED/myRIO $ns duplex-link $n(2) $r(0) 1Mb 5ms DropTail $ns duplex-link $n(2) $r(1) 1Mb 5ms DropTail

One of the sessions runs from node 3 to node 5, periodically transmitting 1000 packets. Therefore, all flows in this session are long according to our definition. On the contrary, in the session from node 4 to node 6, only 4 packets are transmitted in each flow. The simulation script is shown below:

# Create sessions proc build-fore-tcp { idx size intv stime } { global ns ftcp fsink set ftcp($idx) [new Agent/TCP/Newreno] set fsink($idx) [new Agent/TCPSink] $ns at $stime "start-conn 1 $idx $intv $size" } proc start-conn { firsttime idx intv size } { global ns ftcp fsink s r set now [$ns now] if { $firsttime == 0 } { $ns detach-agent $s([expr $idx%2]) $ftcp($idx) $ns detach-agent $r([expr $idx%2]) $fsink($idx) $ftcp($idx) reset $fsink($idx) reset } $ns attach-agent $s([expr $idx%2]) $ftcp($idx) $ns attach-agent $r([expr $idx%2]) $fsink($idx) $ns connect $ftcp($idx) $fsink($idx) $ftcp($idx) set fid_ 0 $ftcp($idx) proc done {} "close-conn $idx $intv $size" $ftcp($idx) advanceby $size } proc close-conn { idx intv size } { global ns set now [$ns now] $ns at [expr $now + $intv] "start-conn 0 $idx $intv $size" puts "at $now + $intv start next" } set forel_intv 1 set fores_intv 0.05 set ssize 4 set lsize 1000 build-fore-tcp 1 $ssize 1 0.1 build-fore-tcp 0 $lsize $forel_intv 0.5 for {set i 0} {$i < 5} { incr i} { build-fore-tcp [expr 2*$i+3] $ssize $fores_intv [expr 1.2+$i*0.1] }

Node 0 is the "size-aware classifier", which counts the incoming packets from each flow. Once the count exceeds a certain threshold (in this case 5), the remaining packets from the corresponding flow are identified as long flow packets. In the simulation, long flow packets are colored in blue. All the other packets, i.e., packets from flows of size less than 5, and the first 5 packets from a long flow, are all identified as short flow packets, and colored in red in the simulation.

To upload a size-aware classifier with threshold set to 5 to node 0, do the following:

# Load a size-aware classifier to node 0 set cls [new Classifier/Hash/SizeAware 128] $cls set default_ -1 $cls set flowlen_thr_ 5 $cls set refresh_intv_ 2 $cls set dynamic_update_ 0 set n(0) [node_with_classifier $cls]

As a result, all packets between node 4 and node 6 are colored in red:

Figure 2: Packets from short flows.

For flows of size bigger than 5, the first 5 packets are colored in red, and the remaining packets are colored in blue:

Figure 3: Packets from long flows.

At the bottleneck link (link between node 1 and node 2), a differentiated dropping scheme is employed. This is achieved by:

$ns duplex-link $n(1) $n(2) 700Kb 25ms RED/myRIO $ns duplex-link-op $n(1) $n(2) orient right Queue/RED/myRIO set gentle_ true Queue/RED/myRIO set thresh_ 1 Queue/RED/myRIO set maxthresh_ 15 Queue/RED/myRIO set weight_ 10 Queue/RED/myRIO set setbit_ false set redq [[$ns link $n(1) $n(2)] queue] $redq set q_weight_ [expr 1.0/2] $redq set linterm_ [expr 4.0] $ns queue-limit $n(1) $n(0) 30

Notice that to obtain a more drastic effect of size-aware differentiation, we choose a relatively high ratio between long and short flow packet dropping rate (weight_ is set to 10).

When congestion happens, low priority packets are dropped at a faster rate (on average 10 times faster) than that for high priority packets. This is illustrated in Figure 4:

Figure 4: More blue packets are dropped than red packets

As a result, high priority flows, or short flows, are transmitted at a rate higher than that of low priority flows, or long flows, as TCP flows are responsive to packet drops. That is the basic scheme of our size-aware scheduling. Figure 5 shows packets generated from the two sessions, after some packets are dropped:


Figure 5: Red packets are generated faster than blue packets.