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 13 18:42:01 2002
  • List-id: RSPlib Discussions <rsplib-discussion.sctp.de>

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
>
calendula#./sipclient -n INVITER.IN
Break Pipe: in=8 out=9
Example Pool User - Version 1.0
-------------------------------

Binding to { 0.0.0.0:57001 }.
Association to 192.168.2.1:9999 => ID #1.
Associate: UseCount increment for A1: 0 -> 1
Association #1 established.
Associate: UseCount decrement for A1: 1 -> 0
Binding to { 0.0.0.0:53286 }.
Association to 192.168.1.1:9999 => ID #2.
Associate: UseCount increment for A2: 0 -> 1
Association #2 established.
Associate: UseCount decrement for A2: 1 -> 0
select: adding FD 1020 for read
select: adding FD 1020 for write
select: adding FD 1020 for except
select: adding FD 1021 for read
select: adding FD 1021 for write
select: adding FD 1021 for except
select: adding FD 13 (1022) with mask $000b
select: registering user callback for socket 13...
Sending Break via break pipe...
select: adding FD 12 (1023) with mask $000b
select: registering user callback for socket 12...
Sending Break via break pipe...
select: waiting...
F0008: User Callback, mask=$1
Break via break pipe received
Break Pipe: 2 calls
A0002: Communication Up Notification
select: wake-up
select: got write for FD 1020.
Sending data to association 2, stream 0:
0b 00 00 04
select: adding FD 1020 for read
select: adding FD 1020 for except
select: adding FD 1021 for read
select: adding FD 1021 for write
select: adding FD 1021 for except
select: adding FD 13 (1022) with mask $000b
select: registering user callback for socket 13...
Sending Break via break pipe...
select: adding FD 12 (1023) with mask $000b
select: registering user callback for socket 12...
Sending Break via break pipe...
select: waiting...
F0008: User Callback, mask=$1
Break via break pipe received
Break Pipe: 2 calls
A0002 S00: Data Arrive Notification, Length = 4
select: wake-up
select: got read for FD 1020.
Waiting... Wakeup!
Received data from association 2, stream 0:
0c 00 00 04
Receive: UseCount decrement for A2: 1 -> 0
A0001: Communication Lost Notification, Status=1
Passive shutdown of association #1!
Unbinding...Unbind complete.
Sending data to association 2, stream 0:
05 00 00 10 00 07 00 09 74 75 6c 69 70 00 00 00
Waiting... select: adding FD 1020 for read
select: waiting...
A0002 S00: Data Arrive Notification, Length = 120
select: wake-up
select: got read for FD 1020.
Waiting... Wakeup!
Received data from association 2, stream 0:
06 00 00 78
Waiting... Wakeup!
Received data from association 2, stream 0:
06 00 00 78 00 07 00 09 74 75 6c 69 70 00 00 00 00 06 00 08 01 00 00 00 00 08
00 30 ee 15 a2 30 f6 b2 1c e4 ff ff ff ff 00 03 00 18 34 8c 00 00 00 01 00 08
c0 a8 01 02 00 01 00 08 c0 a8 02 02 00 06 00 08 01 00 00 00 00 08 00 30 fa 26
e1 d0 f6 b2 1c e4 ff ff ff ff 00 03 00 18 e8 a7 00 00 00 01 00 08 c0 a8 01 04
00 01 00 08 c0 a8 02 04 00 06 00 08 01 00 00 00
Receive: UseCount decrement for A2: 1 -> 0
Connecting to 192.168.1.2:13452...
Binding to { 0.0.0.0:52079 }.
Association to 192.168.1.2:13452 => ID #3.
Associate: UseCount increment for A3: 0 -> 1
Association #3 established.
Associate: UseCount decrement for A3: 1 -> 0
Connection successfully established!
A0003: Communication Up Notification

Sending data to association 3, stream 0:
49 4e 56 49 54 45 20 73 69 70 3a 31 73 30 30 31 40 74 75 6c 69 70 20 53 49 50
2f 32 2e 30 0a 56 69 61 3a 20 53 49 50 2f 32 2e 30 2f 55 44 50 20 63 61 6c 65
6e 64 75 6c 61 3a 37 37 32 30 0a 46 72 6f 6d 3a 20 4d 61 73 74 65 72 20 3c 73
69 70 3a 31 73 30 30 32 40 63 61 6c 65 6e 64 75 6c 61 3e 0a 54 6f 3a 20 53 6c
61 76 65 20 3c 73 69 70 3a 31 73 30 30 31 40 69 72 69 73 3e 0a 43 61 6c 6c 2d
49 44 3a 20 38 34 31 35 36 32 38 33 33 40 63 61 6c 65 6e 64 75 6c 61 0a 43 53
65 71 3a 20 31 20 49 4e 56 49 54 45 0a 43 6f 6e 74 61 63 74 3a 20 3c 73 69 70
3a 31 73 30 30 32 40 63 61 6c 65 6e 64 75 6c 61 3e 0a 43 6f 6e 74 65 6e 74 2d
54 79 70 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 73 64 70 0a 43 6f 6e 74
65 6e 74 2d 4c 65 6e 67 74 68 3a 20 31 34 30 0a 0a 76 3d 30 0a 6f 3d 55 73 65
72 41 20 32 38 39 30 38 34 34 35 32 36 20 32 38 39 30 38 34 34 35 32 36 20 49
4e 20 49 50 34 20 68 65 72 65 2e 63 6f 6d 0a 73 3d 53 65 73 73 69 6f 6e 20 53
44 50 0a 63 3d 49 4e 20 49 50 34 20 31 30 30 2e 31 30 31 2e 31 30 32 2e 31 30
33 0a 74 3d 30 20 30 0a 6d 3d 61 75 64 69 6f 20 34 39 31 37 30 20 52 54 50 2f
41 56 50 20 30 0a 61 3d 72 74 70 6d 61 70 3a 30 20 50 43 4d 55 2f 38 30 30 30
0a 0a

datasocket = 1021
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

result = 0
Active shutdown of association #2 started...
Active shutdown of association #2 complete!
Unbinding...Unbind complete.
Active shutdown of association #3 started...
Active shutdown of association #3 complete!
Unbinding...Unbind complete.
A0002: Communication Lost Notification, Status=1
A0003: Communication Lost Notification, Status=1
Active shutdown of association #2 started...
Active shutdown of association #2 complete!
Unbinding...Unbind complete.
Active shutdown of association #3 started...
Active shutdown of association #3 complete!
Unbinding...Unbind complete.
A0002: Communication Lost Notification, Status=1
A0003: Communication Lost Notification, Status=1
calendula#



Archive powered by MHonArc 2.6.19+.

Top of page