Hi,
I think it is better to stop creating packets when we hit the size limit of
the queue buffer. By doing this, we are certain that we are not losing any
packets. Furthermore, we don't have to create "reservoirs" to store these
created packets so that they can be added into the queue when there is more
space available in the queue. Also we can save tremendous amount of memory
when we are simulating for high-speed networks and better performance.
Regarding the problem in hand, I have been able to control the packet
creation process for different nodes. The problem that I am facing right now
is how to enable back packet creation once we have more space available in
the queue buffer because I am finding it hard to locate where does the
simulater switches to another agent from the one it is currently operating
on and scheduling packets for. Any advice related to this would be a great
help.
Thanks,
- Faisal
On 5/7/06, Faisal Siddiqui <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I appreciate your feedback. I was thinking on the same lines and think it
> is better to block packets at the application layer because of obvious
> reasons. I have a question and would be delighted if someone could share
> some thoughts on it.
>
> My understanding of the network simulator is that the traffic for each
> node is created sequentially. So, I created a mechanism that controls at the
> application layer when to "create" and "halt" creating new packets depending
> on the number of packets in the queue buffer. When the traffic for an agent
> on one node is created, it creates and halts from creating further traffic
> till the time the queue has enough room in it for new packets. But this also
> blocks from creating new traffic for other agents placed on other nodes
> because I disable that piece of code when I hit the queue buffer size for
> one agent placed on a node. Can anybody suggest as to how should I go about
> solving this issue? Any feedback or comments are highly regarded.
>
> Thanks in advance.
> - Faisal
>
>
> On 5/7/06, Ilyes Gouta <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > You could check blocked_ , unblock_on_resume_ and the resume() method
> > inside ns2.2x/queue/queue.cc. You should wrap your new logic inside a
> > new queue by exploiting those switches and adding another queue that
> > will hold all the incoming packets when the primary queue is full
> > (you'll have to pay attention to your inter-arrival and delivery rates
> > and avoid the out of memory condition). This should solve your issues.
> >
> > Another approach would be to the block the packets at the application
> > level not at the queue level by implementing a mechanism to notify the
> > application that it can or can't send packets.
> >
> > Best regards,
> > Ilyes Gouta.
> >
> > Faisal Siddiqui wrote:
> > > Hi,
> > >
> > > I am trying to modify the drop-tail queue so that the queue do not
> > drops
> > > any packets but when the queue maximum size is reached, it stops
> > sending
> > > the packet by stop creating further packets till there is some room
> > > available in the queue. In a nutshell, I want to implement
> > head-of-line
> > > blocking mechanism without dropping any packets.
> > >
> > > I would like to know if someone has implemented such a thing and if
> > yes,
> > > is it possible for them to share the code. If no, please suggest some
> > > ideas as how should I go about implementing this queue.
> > >
> > > All comments are highly appreciated.
> > >
> > > Thanks,
> > > - Faisal
> > >
> > >
> > > On 5/5/06, *Ilyes Gouta* <[EMAIL PROTECTED]
> > > <mailto: [EMAIL PROTECTED]>> wrote:
> > >
> > >
> > > Hi,
> > >
> > > Did you check the TCL binding in the C++ part? The new class
> > should have
> > > a new binding, not the same one as declared for drop-tail.
> > >
> > > Regards,
> > > Ilyes Gouta.
> > >
> > > Eduardo J. Ortega wrote:
> > > > hi:
> > > >
> > > > Don't know if you received my last email, so I'll just write
> > > you again:
> > > >
> > > > I already have the OTCL binding in my newQueue.h file. My sims
> > > define the
> > > > queue like this:
> > > > $ns duplex-link $n1 $n2 1Mb 10ms DropTail (this works)
> > > > but when i try to use my queue then i do
> > > > $ns duplex-link $n0 $n2 1Mb 10ms newQueue
> > > > which doesn't work.
> > > >
> > > > I'm pretty sure this can't be a code problem, since I've copied
> >
> > > and pasted
> > > > drop-tail.{cc,h} to newQueue.{cc,h}, changed classes names and
> > > recompiled but
> > > > still won't work. Can you think of anything else I might be
> > doing
> > > wrong?
> > > > Thanks in advance.
> > > >
> > > > On Saturday 29 April 2006 16:06, you wrote:
> > > >> Hi,
> > > >>
> > > >> You have to create the necessary TCL binding within your new
> > C++
> > > code
> > > >> too. That binding will be used later by your simulation
> > scripts.
> > > >>
> > > >> In the C++ part, you'll have to add a class like this:
> > > >>
> > > >> static class NewQueueClass : public TclClass
> > > >> {
> > > >> public:
> > > >> NewQueueClass () : TclClass("Queue/NewQueue") {}
> > > >> TclObject* create(int, const char*const*)
> > > >> {
> > > >> return (new NewQueue);
> > > >> }
> > > >> } class_new_queue;
> > > >>
> > > >> And then in the simulation script:
> > > >>
> > > >> $ns node-config \
> > > >> option1 \
> > > >> option2 \
> > > >> option3 \
> > > >> -ifqType Queue/NewQueue \
> > > >>
> > > >> This will tell NS to use your new queue for the newly created
> > nodes.
> > > >>
> > > >> Hope it helps,
> > > >> Ilyes Gouta.
> > > >>
> > > >> On 4/29/06, Eduardo J. Ortega < [EMAIL PROTECTED]
> > > <mailto:[EMAIL PROTECTED]>> wrote:
> > > >>> Hi:
> > > >>> I tried this, recompiled ok, but my sims won't run no matter
> > > what my code
> > > >>> is. i thought maybe my code was wrong, so i decided to copy
> > > >>> droptail.{cc,h} to fifo.{c,h}and change class names to FIFO,
> > > then add
> > > >>> fifo.o to makefile and recompiile. It compiled, but again,
> > sims
> > > won't run
> > > >>> when i try to use fifo instead of droptail.
> > > >>>
> > > >>> Any clues?
> > > >>>
> > > >>> On Saturday 29 April 2006 11:11, you wrote:
> > > >>>> Hi,
> > > >>>>
> > > >>>> Have a look into the ~/ns-2.x/queue directory. You'll find
> > all
> > > sorts
> > > >>>> of implementations for different active queues. This include
> >
> > > RED, RIO,
> > > >>>> PRIO, JOBS, etc.
> > > >>>>
> > > >>>> Implementing a new queue is rather easy actually, you'll
> > have to
> > > >>>> inherit from Queue and implement the enque() and deque()
> > > methods. This
> > > >>>> is really it! Don't forget to add you source code to NS's
> > > makefile to
> > > >>>> get it compiled.
> > > >>>>
> > > >>>> Regards,
> > > >>>> Ilyes Gouta.
> > > >>>>
> > > >>>> On 4/29/06, Eduardo J. Ortega <[EMAIL PROTECTED]
> > > <mailto: [EMAIL PROTECTED]>> wrote:
> > > >>>>> hey there:
> > > >>>>>
> > > >>>>> anyone knows how to code new queue algorithms into NS? (for
> >
> > > example,
> > > >>>>> choke)? Thanks.
> > > >>>>>
> > > >>>>> --
> > > >>>>> Eduardo J. Ortega - Linux user #222873
> > > >>>>> "No fake - I'm a big fan of konqueror, and I use it for
> > > everything."
> > > >>>>> -- Linus Torvalds
> > > >>> --
> > > >>> Eduardo J. Ortega - Linux user #222873
> > > >>> "No fake - I'm a big fan of konqueror, and I use it for
> > > everything." --
> > > >>> Linus Torvalds
> > > >
> > >
> > >
> >
>
>
