- From: "Marjan Bozinovski" <marjanb AT cpk.auc.dk>
- To: "Thomas Dreibholz" <dreibh AT exp-math.uni-essen.de>, <rsplib-discussion AT sctp.de>
- Subject: Re: [RSPlib-Discusssion] fail-over problems
- Date: Thu Sep 12 15:22:02 2002
- List-id: RSPlib Discussions <rsplib-discussion.sctp.de>
I understand that a simpler program can facilitate the debugging but I
couldn't do that. On the other hand, today I think at least I localized the
problem. It seems that it has something to do with rspSelect() and the
socket opened by connectToPoolElement().
I will outline a piece of the pseudo code:
1. First I start with:
beginLogging();
initAll();
connectToPoolElement();
//as a result, a global DataSocket is created which is nonzero. This is
the same as in examplepu().
2. I send some data 'buffer'.
sendToPoolElement(buffer);
//this is successfully transmitted as I can see with Ethereal. Also, the
SCTP receiver responds back with SACK + echoed 'buffer'.
3. I start listening to incoming messages:
FD_ZERO(&readfdset);
FD_SET(DataSocket, &readfdset);
timeout.tv_sec = 2;
timeout.tv_usec = 0;
result = rspSelect(DataSocket + 1, &readfdset, NULL, NULL, &timeout);
//exactly as in the examplepu();
After this I always get result=0, there are no incoming messages at
DataSocket.
Why? I am supposed to receive the echoed message from the echo_server.
Where do I make the mistake?
/Marjan
----- Original Message -----
From: "Thomas Dreibholz"
<dreibh AT exp-math.uni-essen.de>
To: "Marjan Bozinovski"
<marjanb AT cpk.auc.dk>;
<rsplib-discussion AT sctp.de>
Sent: Wednesday, September 11, 2002 5:34 PM
Subject: Re: [RSPlib-Discusssion] fail-over problems
>
-----BEGIN PGP SIGNED MESSAGE-----
>
Hash: SHA1
>
>
Am Dienstag, 10. September 2002 23:14 schrieb Marjan Bozinovski:
>
> Hi,
>
>
>
> In my SIP client application I have included a fail-over mechanism. For
>
> instance, if the application does not receive a response to a particular
>
> request after a timer expiration, the request has to be resent to
another
>
> active pool element. In principle, my ultimate goal is if the ASAP level
>
> does the fail-over by using a notification either: a) from the SCTP
layer
>
> that the message could not be delivered to the peer endpoint or b) from
the
>
> ASAP user layer using timer mechanisms as it is at the moment.
>
>
>
> Now, the problem is the following. Whenever a timer activated per SIP
>
> request fires, it is a signal for a failure, and therefore a fail-over
is
>
> made by using the existing function connectToPoolElement() (in
>
> examplepu.c). Here is what I notice: First, it prints on the screen that
>
> the connection to the second PE is successfully established and
>
> connectToPoolElement() is finished. But, when seeing the packets with
>
> Ethereal I realize that the SCTP association is actually not
established.
>
> On the contrary, the SCTP client side sends an INIT but immediately
after
>
> that it sends an ABORT in which it reports zero error causes with the T
bit
>
> set to 0. Due to the abortion, the SCTP association has never been
>
> established although connectToPoolElement() notifies successful
association
>
> startup.
>
>
>
> I also expected that the SCTP association with the previous SCTP
endpoint
>
> will be shutdown, but that does not happen.
>
>
>
> After the connectToPoolElement(), I put sendToPoolElement(), but
naturally
>
> it only says "writing to data socket failed".
>
>
>
> I hope that I described this problem clearly.
>
>
What do you use to realize your timer, Unix signals (SIGALRM, etc.)? The
>
socket API is thread-safe but not signal safe. You can not use socket API
>
functions from a signal handler.
>
>
Turn on loglevel 9 for your rsplib program and let it write the output,
>
including your program's output, to a file, that is "-loglevel=9
>
- -logcolor=off" (see examplepe and examplepu) and ">logfile 2>&1". Then,
send
>
me this file with a description what you have done to produce this output.
>
>
It would be very helpful if you can reproduce the error in a very simple
>
program without your SIP library. The simpler the program, the more easily
I
>
can identify the problem.
>
>
>
Best regards
>
- --
>
=======================================================================
>
Dipl.-Inform. Thomas Dreibholz
>
>
University of Essen, Room ES210
>
Inst. for Experimental Mathematics Ellernstraße 29
>
Computer Networking Technology Group D-45326 Essen/Germany
>
- -----------------------------------------------------------------------
>
E-Mail:
>
dreibh AT exp-math.uni-essen.de
>
Homepage: http://www.exp-math.uni-essen.de/~dreibh
>
=======================================================================
>
>
- -----BEGIN PGP PUBLIC KEY BLOCK-----
>
Version: GnuPG v1.0.6 (GNU/Linux)
>
Comment: Weitere Infos: siehe http://www.gnupg.org
>
>
mQGiBDr2cOgRBAC71Xhy1yzNTBxnousyxwtZ+zxRQJIfkDUQ8Yry5/rdoRkUldnE
>
VQUNX9owxKKwA40DsKMX5lfPIgfPpefqnSOx1/XOtjpffkF8+FY8ncU/LKvHPPw3
>
oNXzFAr8F6NqpJAIbp8eW6DlfraXiJFZk0D6sZyIk9XDqTY01+Dn5WmAewCg4Szj
>
r52geHYk+6n83yfVqw8+c3MD/A9d4ylhJikTHzbL83HTO7WozqlGtZq0rwGY+JIq
>
wPAaRAdBnu0brQz7xtfTZrvxA6v3sYb73bpuosaQNtg1K5Z0l0fbJQxls7wCdSC4
>
GmkXyl64c1bPiGMHu7WVE85mwdm4KyD7qELnnNKZoagFgK1HNYFJtuUDYQ3ihBQq
>
k0VnBACaqJ4k/VJYPQvuWy0fppX+Ultyqz2rrHqqVvaSotjc8muxwM0OL42ZCjL1
>
scuFb1TonojymUFa1nqe6uYU5Owjh2CRfs5+TnMUO7S7vXQRQgWPffIE7kJqL46G
>
S79MmHXVWwmO1WMpJooTlsCUv+J+pAWpYu5nJY4X/s+1DXSA9LQvVGhvbWFzIERy
>
ZWliaG9seiA8ZHJlaWJoQGV4cC1tYXRoLnVuaS1lc3Nlbi5kZT6IVwQTEQIAFwUC
>
OvZw6AULBwoDBAMVAwIDFgIBAheAAAoJEN9gW7B2Dy1l6BcAnRhM7hgy3qOLDKps
>
qIY88XZaMjMqAKDHqpiM/8CFpti9TKeIP/mRbva/3rkCDQQ69nD8EAgApETE6wER
>
FSA5YMQvoqNPYpf8W3y+u+BJvD2QMdKXFy79XnYCoOB26q0JK5gGw1GTB39ANOpc
>
3x5dkSNDiJptntB9DX7SEb1V+GU62XZOhju6o4GbLlhRsy40SVvzZ/RldkoYeCRH
>
1JghU7EkGsn8RcLuRFj7AgW+bWkIyC3NCGZN+mdc/mmRxYqeFpMQv2+Xnb1EuCk6
>
jqDJL6IjVKueYZD5XtKXW+QAj1UlRo9vGpNLs7oZz3QahEgf0S5Cn9eLp2JRr94D
>
FVoInZwziOWyEJ8BrJoydDgCAb/5eEdrAc+7ibuPSOnOxVH8ae9zyNbdimSJGDt1
>
pnfEz/Cw3cYYvwADBwf/bV9iJO22zTJaB5Sz8dzbQfwaa55fugi7DvPOe5eiE1p9
>
/W+uPJTYZ7WQxarM8q/h8BztwOAfeUKztzoGSVvEfxha8Wnvz/3rLWLK1Ok+v9ZV
>
ElrAYmJbbEci1Lmk1vXwmjcYoojYl/25mhkvucg8zVO8WfNYCwBUkGUGUj+SQpbf
>
xEt80dyGm6KFv9XO1fAzlUXkWBODZ4vDPNRY+Ay4evAFkbfKFgHXMUBvtXlGfuSQ
>
pTRXNt0mfRVZ4OeeIKbPdCI8DX5ND9+cIWEQJ2APgWta+h61kwJ5c7k2xxabbYt6
>
v9jTzPr57yvVle4fOV6ExUeCcFaRIzvX+87FMoac+YhGBBgRAgAGBQI69nD8AAoJ
>
EN9gW7B2Dy1lPpwAnR3YQYZRN4WouZwLcGpfMfH2X5RVAKDCa7d6Hwhoa7DrPaTA
>
P/965IPybA==
>
=g36Q
>
- -----END PGP PUBLIC KEY BLOCK-----
>
-----BEGIN PGP SIGNATURE-----
>
Version: GnuPG v1.0.4 (GNU/Linux)
>
Comment: For info see http://www.gnupg.org
>
>
iD8DBQE9f2Kd32BbsHYPLWURAm19AJ4jEG0RlyNIizx+NKFcKeTqcOl/xgCfSbSd
>
NAr80h7BXWpU5MrckfCDcZE=
>
=8cE6
>
-----END PGP SIGNATURE-----
>
_______________________________________________
>
rsplib-discussion mailing list
>
rsplib-discussion AT sctp.de
>
http://www.sctp.de/mailman/listinfo/rsplib-discussion
>
Archive powered by MHonArc 2.6.19+.