First login?
Lost password?
 
 
rsplib-discussion AT lists.franken.de 
RSPlib Discussions

Text archives Help


Re: [RSPlib-Discusssion] fail-over problems


Chronological Thread 
  • From: Thomas Dreibholz <dreibh AT exp-math.uni-essen.de>
  • To: "Marjan Bozinovski" <marjanb AT cpk.auc.dk>, <rsplib-discussion AT sctp.de>
  • Subject: Re: [RSPlib-Discusssion] fail-over problems
  • Date: Wed Sep 11 17:42:00 2002
  • List-id: RSPlib Discussions <rsplib-discussion.sctp.de>
  • Organization: University of Essen, Institute for Experimental Mathematics
-----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-----


Archive powered by MHonArc 2.6.19+.

Top of page