The traditional streaming has been done by using streaming
technologie used before by Microsoft; In this case some tools have been taken
in consideration such as:
· A computer network.
· A video file with 360 Kbs that has been taken as
sample.
· A web server that helped to stream the file above
· And Iris Network Analyzer for analyzing network
performance and quick relay of multimedia services in general and a video file
in our case.
· Three computers; the first one worked as server and the
other two as client.
III. 3.1.1 HIGHLEVEL NETWORK DIA GRAM FOR TRADITIONNAL
STREAMING
In traditional streaming, video file has been posted into the
web server on which the client makes access to the server by using the hyper
text transfer protocol (http).
III. 3.1.2 NETWORK PERFOMANCE RESULT
After testing the latency of traditional streaming, the results
got are as follow:
As mentioned, the file used has 360 Kbs of size. The traffic of
packets started at 22:16:26 and ended at 22:16:39.
Table 1: Bandwidth test for traditional streaming
Source: Own Result
4000
2500
2000
3500
3000
1500
1000
500
0
hours
Packets/Sec
Figure 19: Bandwidth diagram for traditional streaming
Source: Own Result
During traditional streaming the number of packets is
occupying the bandwidth and it is varying between 0 and 4000 packets per second
which show that there has been a big number ofpackets in traffic.
III. 3.1.2 THE REAL-TIME CHALLENGE
Multimedia networking is not a trivial task. We can expect at
least three difficulties.
First, compared with traditional textual applications,
multimedia applications usually require much higher bandwidth. A typical piece
of 25 second 320x24 movies could take about 2.3MB, which is equivalent to about
1000 screens of textual data. This is unimaginable in the old days when only
textual data is transmitted on the net.
Second, most multimedia applications require the real-time
traffic. Audio and video data must be played back continuously at the rate they
are sampled.
If the data does not arrive in time, the playing back process
will stop and human ears and eyes can easily pick up the artifact. In Internet
telephony, human beings can tolerate a latency of about 250 milliseconds.
If the latency exceeds this limit, the voice will sound like
a call routed over a long satellite circuit and users will complain about the
quality ofthe call. In addition to the delay, network congestion also has more
serious effects on real-time traffic.
If the network is congested, the only effect on non-realtime
traffic is that the transfer takes longer to complete, but real-time data
becomes absolute and will be dropped if it doesn't arrive in time. If no proper
reaction is not taken, the retransmission of lost packets would aggravate the
situation andjam the network.
Third, multimedia data stream is usually bursty. Just
increasing the bandwidth will not solve the burstiness problem. For most
multimedia applications, the receiver has a limited buffer. If no measure is
taken to smooth the data stream, it may overflow or underflow the application
buffer.
When data arrives too fast, the buffer will overflow and the
some data packets will be lost, resulting in poor quality. When data arrives
too slowly, the buffer will underflow and the application will starve.
Contrary to the high bandwidth, real-time and bursty traffic
of multimedia data, in real life, networks are shared by thousands and millions
of users, and have limited bandwidth, unpredictable delay and availability. How
to solve these conflicts is a challenge multimedia networking must face.
The possibility of answering this challenge comes from the
existing network software architecture and fast developing hardware. The basis
of Internet, TCP/IP and UDP/IP, provides a range of services that multimedia
applications can use.
Fast networks like Gigabit Ethernet, FDDI, and ATM provide
high bandwidth required by digital audio and video. So the design of real-time
protocols for multimedia networking becomes imperative before the multimedia
age comes.
