[tg] abt srource IP addr in server log..
Barbara Denny
b_a_denny at yahoo.com
Wed Apr 19 16:40:47 PDT 2006
Hello,
You must remember TG is only a user process. Whatever
happens regarding source address selection takes
place in the kernel if you have not specified it.
It is possible to tell the kernel which source
address you want to use if their are multiple ones.
In TG there is undocumented feature of giving 2 IP
addresses in the association spec. The first one is
the source; the second is the destination. Glancing
at the code, it looks like it is set up to work with
udp, but not tcp (testing also seems to verify this).
If you really want to force the binding to a
particular
source address when you BEGIN the tcp connection,
you can modify the code (see prot_dgram.c for an
example. The change would be made in prot_stream.c).
I might be able to make the change and test it out
soon to verify it works for TCP.I just don't have
the time today and I won't have the time to do an
official release of TG soon.
Remember on the receive side you can use
INADDR_ANY (0.0.0.0) in the script to accept the
"connection" from any address. The source
address of the data flow will be recorded in
the ouput file for the data sink. If the source
address doesn't change when you are using
udp, I imagine this is just the way things
work in the linux kernel. Even though the
path is now through you other link, the source
address doesn't get modified. I don't have
the resources to replicate your test case.
I am not sure what you asking me regarding
ressession setup with TCP. I am not sure exactly
what you are trying to do and what behaviour you are
seeing. If the TCP connection breaks when you change
links, myy immediate reaction is to think the problem
you are having with TG and TCP has nothing to do
with TG and TG cannot "fix" it. It has to do with
the Internet architecture. TCP uses the IP address
to help identify the connection. If you do something
to force the IP address to "change", you will cause
the connection to break. However, maybe you want to
do something else but I need to understand what that
is. Right now I don't know. Now if the kernel really
doesn't bother to "invalidate" the source address
when it uses a different interface then there is
a chance the tcp connection won't break. Again, I
don't have the resources to replicate your test.
You could try running tcpdump to see what goes
on the wire in the udp and tcp case. It is interesting
that you are reporting that UDP doesn't change
its source address when you cause packets to
use the other link. This would make me think that
the TCP connection might have a chance of staying
up. Now whether this is the correct behavior is
another question...
Overall it sounds like you are trying to show
some type of fault tolerant behavior, versus emulating
mobility. In some ways, the problem is similar
so I suggest looking into those areas to deepen
your understanding. There probably is also some
discussion of it under the topic of multihoming too.
barbara
--- prashant soni <soni_prash at yahoo.co.uk> wrote:
>
> dear barbara
> thnx it seems it will work for me as u have rightly
> pointed out abt [ ] in using options,..
>
> one more problem i am facing..
>
> actually i have set a kind of demonstration for
> redundent communication between two Fedora core3
> machines connected through two crossover cable (one
> primary another secondary channel) Two NIC in each
> comp..Two IP for each comp...
> now data usually goes thru primary srource IP ,
> (primary cable.) and .if i unplug it it goes thru
> secondary channel (cable)..thru secondary srs IP..
> to destination..
> [ little static routing table database trick ]
> n it works for UDP..for TCP applications it
> requires resession setup..
>
> now my problem is when i use TG for generating
> random UDP packets at server log it shows only one
> srs IP address..though i have unpluged that cable n
> data r coming from secondary cable thru seconadry
> NIC.. TG server log shows same IP for source..why
> ?????
> hope i m clear in my question..
>
> for TCP application .. resession setup how could i
> employ in TG whenever primary chennel goes
> out...some hints r welcome
>
> thanx..
>
> Flying is learning how to throw yourself at the
> ground and miss.
> Prashant Soni
> Room No 330, Sarayu Hostel
> IIT Madras, Chennai - 36,mo no 09380552468
> _______________________________________________
> tg mailing list
> tg at postel.org
> http://www.postel.org/mailman/listinfo/tg
> _______________________________________________
> tg mailing list
> tg at postel.org
> http://www.postel.org/mailman/listinfo/tg
>
More information about the tg
mailing list