- From: Andreas Jungmaier <ajung AT exp-math.uni-essen.de>
- To: "'Thorbjørn Jørgensen'" <thjo02 AT kom.auc.dk>
- Cc: discussion AT sctp.de
- Subject: Re: [SCTP-Discussion] Unexpected timegap...
- Date: Thu Jun 10 15:02:00 2004
- List-id: SCTP Discussions <discussion.sctp.de>
- Organization: University Duisburg-Essen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thorbjørn,
please see my comments below inline:
On Donnerstag, 10. Juni 2004 13:19, 'Thorbjørn Jørgensen' wrote:
>
Hi
>
We have been testing different primitive handover scenarios using SCTP by
>
using the SetRemotePath implementation in sctplib 1.1.6, and have come up
>
with an unexpected result. The setup is as follows: A server running a
>
modified version of the daytime servers, which repeatedly sends out SCTP
>
packets with predefined inter packet time, when an association is created
>
and until the association is shutdown. The server only got one NIC. A node
>
which is running a slightly modified version of the terminal, and which
>
haves two NIC located in two different subnets, is creating an association
>
with the server, where both IP addresses of the NICs are added. During the
>
association the node sends a SetRemotePrimary (SETPRIM through the
>
terminal) so the connection is handed over to the other interface. The
>
problem is that when changing from NIC1 to NIC2 the handover time is
>
approximately 0.1s with a low variance, but when changing from NIC2 to NIC1
>
the handover time is 3s with a low variance. The problem is to explain why
>
it takes exactly 3s before the handover is carried out? Is it some timer in
>
sctplib that causes this? It should be said that there are differences in
>
the handling of NIC1 and NIC2 since one is Bluetooth and the other is WLAN,
>
and this will probably explain why the 3s gap only occurs in one direction,
>
but what I causing the 3s?
As a matter of fact, I have no idea -- maybe, since the scenario does not
seem to involve a massive data transfer, could you try to create a logfile,
compress it, and send it to me ?
(for this you need to set the constants
Current_event_log_ 6
and
Current_error_log_ 4
ans recompile SCTPLIB and your applications. Then place the attached file
in the directory where your application runs. Running the application should
give you a file named tmpXYZ.log, that you can compress via gzip.
Also: which operating system/version are you running ?
>
Another (shorter) question: Is there a plan for when ADD_IP and DELETE_IP
>
to/from an association will be implemented into sctplib?
Depending on the OS you are using, 1.1.6 *does* support the ADD-IP extension.
However, the API may not be clear or obvious. The registered SCTP instances
are notified by the routing socket when the IP addresses of a host system
change.
If you register the SCTP instance with a local address of INADDR_ANY,
and simply do an "ifconfig eth1 blablabla up" (assuming this command
correctly
configures the new interface/address), and both sides support ADD-IP, then
you should be able to trace an ADD-IP chunk (e.g. by using ethereal).
Best regards,
Andreas
- --
Dipl.-Ing. Andreas Jungmaier
Computer Networking Technology Group
University of Duisburg-Essen
http://www.exp-math.uni-essen.de/~ajung
PGP Key-ID: D382 4AC0
PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAyFrhXAsLBNOCSsARAsRmAJ4smzygQmUtNhsVQFVfYeqYyafY7QCfWglF
ZvUArFOPUcfN3Nm4zshASPw=
=Qwbi
-----END PGP SIGNATURE-----
LOGFILE
Archive powered by MHonArc 2.6.19+.