RSPlib Discussions

Text archives Help


[RSPlib-Discusssion] connectToPoolElement()


Chronological Thread 
  • From: "Marjan Bozinovski" <marjanb AT cpk.auc.dk>
  • To: <rsplib-discussion AT sctp.de>
  • Subject: [RSPlib-Discusssion] connectToPoolElement()
  • Date: Tue Oct 22 12:07:01 2002
  • List-id: RSPlib Discussions <rsplib-discussion.sctp.de>

Hi Thomas,
 
I have some news concerning your last suggestion on using threads instead of using fork() for handling multiple simultaneous processes. The only reason the program uses fork() is to distinguish between different testcases, which may be executed simultaneously. However, this is not necessary, since for my purposes I need to use only one testcase, therefore I can completely avoid multiple processes.
 
There is something else that seems to be a little problem. It occurs in both my program and examplepu.c. This is the problem description:
 
Let us consider a pool with two PEs. An SCTP association between a PU and PE1 has already been established. But, due to some reason (e.g., timer expiration due to a missing response) I decide to do a fail-over to PE2 and resend an application message to PE2. Thus, I do the following:
 
connectToPoolElement();
sendToPoolElement(message); //this is a modified version of the original sendToPoolElement().
 
The result of the execution of sendToPoolElement(message) is "writing to data socket failed", i.e., an unsuccessful message transmission over the SCTP association PU<->PE2, although this association has already been established as seen on Ethereal.
 
I realized that sending the message comes too fast after the SCTP association is established. So, I did the following change:
 
connectToPoolElement();
poll(NULL, 0, 30);
sendToPoolElement(message);
 
Now, the message transmission to PE2 is successful. The minimum delay for which this still works is 20 msec. Definitely, the message transmission over the new SCTP association comes too fast after its establishment, and probably the SCTP endpoint is still not ready to write the data to the socket.
 
That's why I say that this is not a big problem, but a certain limitation of the implementation.
 
Best regards,
Marjan



Archive powered by MHonArc 2.6.19+.

Top of page