Chronological Thread 

< Chronological >      < Thread >

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Dienstag, 22. Oktober 2002 12:09 schrieb Marjan Bozinovski:
> 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.

If you are using the same version of connectToPoolElement() as in
examplepu.c, the ext_select() call after the ext_connect() should wait until
the connection is successfully established. The ext_connect() itself
immediately returns, since the socket is set to non-blocking. Therefore, the
ext_select() is necessary.
Please check if the ext_select() is executed and that there is no fork(). If
the source is okay, send me the debug output (including all the debug
#defines in the socket API enabled as for finding the fork() problem). Also
send me your latest source, so I can try to reproduce it on our FreeBSD
machine.


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 SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9tShD32BbsHYPLWURAllmAJwPN9dO8ZdetCS9/nmhKoNYRWBTSACg0nNy
GgiMUM6UuIXcseFx50DLEpY=
=bS4q
-----END PGP SIGNATURE-----

---

• [RSPlib-Discusssion] connectToPoolElement(), Marjan Bozinovski, 10/22/2002
  • Re: [RSPlib-Discusssion] connectToPoolElement(), Thomas Dreibholz, 10/22/2002
    • Re: [RSPlib-Discusssion] connectToPoolElement(), Marjan Bozinovski, 10/22/2002
      • Re: [RSPlib-Discusssion] connectToPoolElement(), Thomas Dreibholz, 10/22/2002
        • Re: [RSPlib-Discusssion] connectToPoolElement(), Marjan Bozinovski, 10/22/2002

---

Archive powered by MHonArc 2.6.19+.