To Get any Project for CSE, IT ECE, EEE Contact Me @ 09666155510, 09849539085 or mail us - ieeefinalsemprojects@gmail.com-Visit Our Website: www.finalyearprojects.org

1. GLOBALSOFT TECHNOLOGIES
IEEE PROJECTS & SOFTWARE DEVELOPMENTS
IEEE FINAL YEAR PROJECTS|IEEE ENGINEERING PROJECTS|IEEE STUDENTS PROJECTS|IEEE
BULK PROJECTS|BE/BTECH/ME/MTECH/MS/MCA PROJECTS|CSE/IT/ECE/EEE PROJECTS
CELL: +91 98495 39085, +91 99662 35788, +91 98495 57908, +91 97014 40401
Visit: www.finalyearprojects.org Mail to:ieeefinalsemprojects@gmail.com
Receiver-Based Flow Control for
Networks in Overload
Abstract:
We consider utility maximization in networks where the sources do not
employ flow control and may consequently overload the network. In the absence of
flow control at the sources, some packets will inevitably have to be dropped when
the network is in overload. To that end, we first develop a distributed; threshold
based packet-dropping policy that maximizes the weighted sum throughput. Next,
we consider utility maximization and develop a receiver-based flow control
scheme that, when combined with threshold-based packet dropping, achieves the
optimal utility. The flow control scheme creates virtual queues at the receivers as a
push-back mechanism to optimize the amount of data delivered to the destinations
via back-pressure routing. A new feature of our scheme is that a utility function
can be assigned to a collection of flows, generalizing the traditional approach of
optimizing per-flow utilities. Our control policies use finite-buffer queues and are
independent of arrival statistics. Their near-optimal performance is proved and
further supported by simulation results.
Existing System:
In the existing system, the sender sends the packets without the
intermediate station. The data packets has been losses many and time is wasted.
Retransmission of data packets is difficulty in Existing TCP specification. The
standard already requires receivers to report the sequence number of the last in-

2. order delivered data packet each time a packet is received, even if received out of
order. For example, in response to a data packet sequence 5,6,7,10,11,12, the
receiver will ACK the packet sequence 5,6,7,7,7,7. In the idealized case, the
absence of reordering guarantees that an out-of-order delivery occurs only if some
packet has been lost. Thus, if the sender sees several ACKs carrying the same
sequence numbers (duplicate ACKs), it can be sure that the network has failed to
deliver some data and can act accordingly.
Proposed System:
Measured traffic rates and buffer sizes, the number of congestive packet
losses that will occur. The Host to Host congestion control proposals that build a
foundation for all currently known host-to-host algorithms. This foundation
includes
1) The basic principle of probing the available network resources,
2) Loss-based and delay-based techniques to estimate the congestion state in
the network.
3) Techniques to detect packet losses quickly TCP standard specifies a
sliding window based flow control.
This flow control has several mechanisms. First, the sender buffers all data
before the transmission, assigning a sequence number to each buffered byte. The
former, a cumulative ACK, indicates that all data blocks having smaller sequence
numbers have already been delivered. The latter, a selective ACK explicitly
indicates the ranges of sequence numbers of delivered data packets. To be more
precise, TCP does not have a separate ACK packet, but rather uses flags and option
fields in the common TCP header for acknowledgment purposes. (A TCP packet
can be both a data packet and an ACK packet at the same time.) However, without
loss of generality, we will discuss a notion of ACK packets as a separate entity.
Hardware Requirement:
System : Pentium IV 2.4 GHz.

3. Hard Disk : 40 GB.
Floppy Drive : 1.44 Mb.
Monitor : 15 VGA Colour.
Ram : 256 Mb.
Software Requirement:
Operating system : Windows XP Professional.
Coding Language : Java
IDE : NetBeans 7.0.1