- From: "Marjan Bozinovski" <marjanb AT cpk.auc.dk>
 
- To: "Thomas Dreibholz" <dreibh AT irmgard.exp-math.uni-essen.de>,	<rsplib-discussion AT sctp.de>
 
- Subject: Re: [RSPlib-Discusssion] fail-over problems
 
- Date: Tue Oct  1 15:22:00 2002
 
- List-id: RSPlib Discussions <rsplib-discussion.sctp.de>
 
 
Hi Thomas,
I am sorry to be so delayed, from 21st of September until yesterday I was
out of office and I was not able to check my e-mail. Now, I am back and I
did according to the suggestions in your last mail. And here is what I've
got.
First, I set timeout.tv_sec to 20 seconds and realized that it is definitely
the select timeout that wakes up the ext_select because the debug line
"select: wake-up" shows up immediately after its expiration.
Second, I recompiled the libraries as you described and this is the debug
output I get:
-----------------
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
broadcast: SCTPAssociation::InQueue
broadcast: SCTPAssociation::ReadUpdateCondition
select: wake-up
Condition 0 (Type 1020, FD 134880283) not fired
Condition 2 (Type 1020, FD 134880283) not fired
Condition 0 (Type 1021, FD 134880283) not fired
-----------------
What confuses me is actually the fact that my client application is
essentially very similar to the program examplepu.c. It uses the same
sequence of functions:
-------
connectToPoolElement();
sendToPoolElement(buffer);
rspSelect();
-------
The difference is that mine is an external application with respect to the
rsplib and socketapi.
Best regards,
Marjan
----- Original Message -----
From: "Thomas Dreibholz" 
<dreibh AT irmgard.exp-math.uni-essen.de>
To: "Marjan Bozinovski" 
<marjanb AT cpk.auc.dk>;
 
<rsplib-discussion AT sctp.de>
Sent: Monday, September 23, 2002 3:30 PM
Subject: Re: [RSPlib-Discusssion] fail-over problems
>
 -----BEGIN PGP SIGNED MESSAGE-----
>
 Hash: SHA1
>
>
 On Montag, 16. September 2002 11:46, Marjan Bozinovski wrote:
>
 > 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.
>
 >
>
>
 I was on holiday, without laptop and Internet access, therefore the late
>
 reply.
>
>
 In the logfile, the ext_select wake-up seems to be caused by the data
arrival.
>
 To be sure it is not the select timeout, set timeout.tv_sec to a very
large
>
 value first and check it.
>
>
 In case the select wake-up is correctly caused by the data arrival, there
must
>
 be a read condition. This is checked about line 2620 in
sctpsocketwrapper.cc.
>
 Use the following code here:
>
>
    int changes = 0;
>
    for(cardinal i = 0;i < selectData.Conditions;i++) {
>
       if(selectData.ConditionArray[i]->fired()) {
>
>
 // NEW
>
 printf("Condition %d (Type %d, FD %d)
>
 fired!\n",i,selectData.ConditionType[i],selectData.ConditionFD[i]);
>
 // ---
>
>
          changes++;
>
          switch(selectData.ConditionType[i]) {
>
          ...
>
       }
>
>
 // NEW
>
       else {
>
          printf("Condition %d (Type %d, FD %d)      not
>
 fired\n",i,selectData.ConditionType[i],selectData.ConditionFD[i]);
>
       }
>
 // ---
>
>
>
selectData.ConditionArray[i]->removeParent(selectData.ParentConditionArray[i
]);
>
    }
>
>
>
 Now, uncomment line 48 in condition.cc (#define PRINT_SIGNAL); this will
print
>
 out some debug information about the conditions. Use "gmake clean" and
"gmake
>
 install" to ensure complete recompilation and reinstallation of the
changed
>
 socket API code. Then, recompile rsplib with "gmake clean" and "gmake".
>
>
 My idea for the problem is that possibly somewhere the read condition's
>
 "fired" state is lost and therefore the readfd will not be set. The next
>
 logfile will hopefully locate it.
>
>
>
 Best regards
>
 - --
>
 =======================================================================
>
  Dipl.-Inform. Thomas Dreibholz
>
  Molbachweg 7
>
  D-51674 Wiehl-Forst    Mail: 
>
 dreibh AT exp-math.uni-essen.de
>
  Germany                WWW:  http://www.exp-math.uni-essen.de/~dreibh
>
 =======================================================================
>
 -----BEGIN PGP SIGNATURE-----
>
 Version: GnuPG v1.0.6 (GNU/Linux)
>
 Comment: For info see http://www.gnupg.org
>
>
 iD8DBQE9jxeQ32BbsHYPLWURAr8KAKCM3Dqon2NwgHcFnK349ZDko8xYsgCgq0Z3
>
 0ZBa7PEou9E4Acd7SR2/HsY=
>
 =wLDC
>
 -----END PGP SIGNATURE-----
>
>
 _______________________________________________
>
 rsplib-discussion mailing list
>
 rsplib-discussion AT sctp.de
>
 http://www.sctp.de/mailman/listinfo/rsplib-discussion
>
- Re: [RSPlib-Discusssion] fail-over problems, Marjan Bozinovski, 10/01/2002
 
Archive powered by MHonArc 2.6.19+.