RSPlib Discussions

Text archives Help


Re: [RSPlib-Discusssion] fail-over problems


Chronological Thread 
  • 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+.

Top of page