Chronological Thread 

< Chronological >      < Thread >

---

Hi Michael,

Our server-application is multithreaded.

1) One thread is generating the load, this thread is sending the packet to
client-application
2) Main thread is processing the packets received from client-application

Is there any problem in sctp 1.0.5 library, if the application is
multithreaded.
how to over come this problem

Regards
Nigar


----- Original Message -----
From: "Michael Tuexen"
<Michael.Tuexen AT micmac.franken.de>
To: "Nigar"
<nigar AT teledna.com>
Cc:
<sctp-discussion AT sctp.de>
Sent: Tuesday, February 05, 2008 10:45 PM
Subject: Re: [SCTP-Discussion] Issue faced by server-application, using sctp
1.0.5 library


> Hi Nigar,
>
> as Thomas already suggested: Please use an updated version of the
> library. We did
> not change the API, so it should be easy for you to change it.
>
> Are you using a single threaded or multithreaded application?
>
> Best regards
> Michael
>
> On Feb 5, 2008, at 12:55 PM, Nigar wrote:
>
> > Hi All,
> >
> > Our application is using sctp 1.0.5 library, this library we have
> > downloaded from www.sctp.de site.
> >
> > We have two applications, one acting as server and other one client.
> > Our application are not handling more than 1 msg/sec for more than 2
> > minutes.
> >
> > Each time during the load condition we are seeing some problems in
> > server-application and server-application is core dumping
> > (segmentation fault):
> >
> > 1. server-application is core dumping in sort_tsn function:
> > #0 0x08136cf3 in sort_tsn (one=0x81ce8e4, two=0x0) at globals.c:84
> > #1 0x4006cec1 in g_list_insert_sorted () from /usr/lib/
> > libglib-1.2.so.0
> > #2 0x081336ba in rtx_save_retrans_chunks (data_chunk=0x81d29e8) at
> > reltransfer.c:906
> > #3 0x0813845f in fc_check_for_txmit (fc_instance=0x81d16d8,
> > oldListLen=1, doInitialRetransmit=0) at flowcontrol.c:710
> > #4 0x08138815 in fc_send_data_chunk (chunkd=0x81d29e8,
> > destAddressIndex=-1, lifetime=4294967295, dontBundle=136129000,
> > context=0x81d29e8) at flowcontrol.c:997
> > #5 0x0813150c in se_ulpsend (streamId=0, buffer=0x409e399c "\001",
> > byteCount=207, protocolId=67108864,
> > destAddressIndex=-1, context=0x0, lifetime=4294967295,
> > unorderedDelivery=135634792, dontBundle=1) at streamengine.c:458
> > #6 0x0812527e in sctp_send_private (associationID=1, streamID=0,
> > buffer=0x409e399c "\001", length=207,
> > protocolId=67108864, path_id=-1, context=0x0,
> > lifetime=4294967295, unorderedDelivery=135634792, dontBundle=1)
> > at distribution.c:2325
> >
> > 2. server-application is core dumping in chunk_list_debug function:
> > #0 0x08133967 in chunk_list_debug (event_log_level=6,
> > chunk_list=0x81ce750) at reltransfer.c:946
> > #1 0x0813381c in rtx_save_retrans_chunks (data_chunk=0x8204450) at
> > reltransfer.c:916
> > #2 0x08138563 in fc_check_for_txmit (fc_instance=0x81d1520,
> > oldListLen=1, doInitialRetransmit=0) at flowcontrol.c:755
> > #3 0x08138919 in fc_send_data_chunk (chunkd=0x8204450,
> > destAddressIndex=-1, lifetime=4294967295, dontBundle=0, context=0x0)
> > at flowcontrol.c:1016
> > #4 0x0813164c in se_ulpsend (streamId=0, buffer=0x409e399c "\001",
> > byteCount=207, protocolId=4, destAddressIndex=-1,
> > context=0x0, lifetime=4294967295, unorderedDelivery=136115224,
> > dontBundle=1) at streamengine.c:367
> > #5 0x081253ce in sctp_send_private (associationID=1, streamID=0,
> > buffer=0x409e399c "\001", length=207, protocolId=4,
> > path_id=-1, context=0x0, lifetime=4294967295,
> > unorderedDelivery=136115224, dontBundle=1) at distribution.c:2325
> >
> > 3. server-application is core dumping in timercompare function:
> > #0 timercompare (a=0x81cf490, b=0x0) at timer_list.c:73
> > #1 0x4006cec1 in g_list_insert_sorted () from /usr/lib/
> > libglib-1.2.so.0
> > #2 0x08130ca1 in insert_item (item=0x81cf490) at timer_list.c:137
> > #3 0x0812beb3 in adl_startMicroTimer (seconds=1,
> > microseconds=1202209248, timer_cb=0x81cf490, ttype=136115344,
> > param1=0x81cf490, param2=0x81cf490) at adaptation.c:1943
> > #4 0x0812bef8 in adl_startTimer (milliseconds=1202209248,
> > timer_cb=0x8137cac <fc_timer_cb_t3_timeout>, ttype=3,
> > param1=0x81d1544, param2=0x81d1590) at adaptation.c:1957
> > #5 0x081384b3 in fc_check_for_txmit (fc_instance=0x81d1520,
> > oldListLen=0, doInitialRetransmit=0) at flowcontrol.c:806
> > #6 0x08138929 in fc_send_data_chunk (chunkd=0x8231e18,
> > destAddressIndex=-1, lifetime=4294967295, dontBundle=136115344,
> > context=0x81cf490) at flowcontrol.c:1016
> > #7 0x0813164c in se_ulpsend (streamId=0, buffer=0x409e399c "\001",
> > byteCount=207, protocolId=4, destAddressIndex=-1,
> > context=0x0, lifetime=4294967295, unorderedDelivery=136115584,
> > dontBundle=1) at streamengine.c:367
> > #8 0x081253ce in sctp_send_private (associationID=1, streamID=0,
> > buffer=0x409e399c "\001", length=207, protocolId=4,
> > path_id=-1, context=0x0, lifetime=4294967295,
> > unorderedDelivery=136115584, dontBundle=1) at distribution.c:2325
> >
> > Please suggest us what could be the problem, the server-application
> > is dumping always while sending data to client-application.
> >
> > Regards
> > Nigar
> >
> >
> > _______________________________________________
> > sctp-discussion mailing list
> > sctp-discussion AT sctp.de
> > http://www.sctp.de/mailman/listinfo/sctp-discussion
>
>

---

• [SCTP-Discussion] Issue faced by server-application, using sctp 1.0.5 library, Nigar, 02/05/2008
  • <Possible follow-up(s)>
  • [SCTP-Discussion] Issue faced by server-application, using sctp 1.0.5 library, Nigar, 02/05/2008
    • Re: [SCTP-Discussion] Issue faced by server-application, using sctp 1.0.5 library, Thomas Dreibholz, 02/05/2008
    • Re: [SCTP-Discussion] Issue faced by server-application, using sctp 1.0.5 library, Michael Tuexen, 02/05/2008
      • Re: [SCTP-Discussion] Issue faced by server-application, using sctp 1.0.5 library, Nigar, 02/06/2008

---

Archive powered by MHonArc 2.6.19+.