First login?
Lost password?
 
 
rsplib-discussion AT lists.franken.de 
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 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
>



Archive powered by MHonArc 2.6.19+.

Top of page