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: Fri Sep 20 11:32:00 2002
  • List-id: RSPlib Discussions <rsplib-discussion.sctp.de>

Hi Thomas,

I just want to ask you if you have examined the debugging output lines I
sent you on Monday. What do you think, is the problem located in my
application or it has to do with its interface to rsplib, socketapi and
sctplib?

Best regards,
Marjan


> Hi Thomas,
>
> In the logfile I sent you on Friday, one can see that the problem occurs
> with the rspSelect(). These are the suspicious debugging output line:
>
> -----------------------
> select: adding FD 0 (0) with mask $0003
> select: registering user callback for socket 0...
> Sending Break via break pipe...
> F0008: User Callback, mask=$1
> Break via break pipe received
> Break Pipe: 1 calls
> select: adding FD 1020 for read
> select: adding FD 1020 for except
> select: adding FD 1021 for read
> select: waiting...
> A0003 S00: Data Arrive Notification, Length = 392
> select: wake-up
> ----------------------
>
> It's strange, there is Data Arrive Notification, but rspSelect() returns
> zero. What is the problem? This does not happen when examplepu is run.
>
> Best regards,
> Marjan
>
>
> ----- Original Message -----
> From: "Marjan Bozinovski"
> <marjanb AT cpk.auc.dk>
> To: "Thomas Dreibholz"
> <dreibh AT exp-math.uni-essen.de>;
> <rsplib-discussion AT sctp.de>
> Sent: Friday, September 13, 2002 6:42 PM
> Subject: Re: [RSPlib-Discusssion] fail-over problems
>
>
> > Thomas, I didn't receive your last two mails. An hour ago, I accidently
> > checked the rsplib mailing list archive, and I saw you messages. So, I
did
> > as you recommended and in the attached file I put the debug output I get
> on
> > the screen after turning on the socket API debugging output.
> >
> > Note that I set my program to exit automatically if rspSelect() does not
> > report any arrived message (i.e., result=0).
> >
> > Please check it out and see if there is something suspicious.
> >
> > Regards,
> > Marjan
> >
> > ----- Original Message -----
> > From: "Marjan Bozinovski"
> > <marjanb AT cpk.auc.dk>
> > To: "Thomas Dreibholz"
> > <dreibh AT exp-math.uni-essen.de>;
> > <rsplib-discussion AT sctp.de>
> > Sent: Thursday, September 12, 2002 3:20 PM
> > Subject: Re: [RSPlib-Discusssion] fail-over problems
> >
> >
> > > 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
> > > >
> > >
> > > _______________________________________________
> > > rsplib-discussion mailing list
> > > rsplib-discussion AT sctp.de
> > > http://www.sctp.de/mailman/listinfo/rsplib-discussion
> > >
> >
>
> _______________________________________________
> 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