Chronological Thread 

< Chronological >      < Thread >

---

Hi! I found the reason of the behaviour described in p. 2) in my previous
mail.
This is very simple. the size of received message is just strictly restricted
approximately by the value of rwnd of receiver. So, receiver just didn't
receive
the messages of size greater than 3*SCTP_MAXIMUM_DATA_LENGTH
( my_rwnd = 4096 ).

Sorry for alert.

Best regards,
Michael

----- Original Message -----
From: "Michael Nikolaev"
<mvn AT gu.kiev.ua>
To: "Andreas Jungmaier"
<ajung AT exp-math.uni-essen.de>
Cc:
<discussion AT sctp.de>
Sent: Friday, August 30, 2002 11:44 PM
Subject: Re: [SCTP-Discussion] Bug in SACK processing


> Hi,
>
> The scenario was as follows:
>
> I written two applications: one operating as a server, another - as a
> client. Client sends to
> server messages of the size and number specified in the command line.
> Messages are sent
> in the "bundling enabled" mode. I observed two bugs in behaviour:
> 1) When messages are of the size 40 bytes or less I have a reference to
> memory that
> has been free(). The reason of this bug I already mentioned.
> 2) When messages are of the size > 3*1400 = 4200 bytes I observe the
> conversation
> starts and stops after 6 chunks was sent. I had no time yet to investigate
> the reason.
> Visually, no more chunks are sent and the server sends to client a packet
> time from time.
> I used the same diagnostic output [measurementTimerRunOffFunction()] as in
> the application localcom.c and my own diagnostics marked with "***" that
> shows how many
> packets have been sent and received during 1 last second. The traces are
> as foolows:
>
> >testClien -s 192.168.0.14 -d 192.168.0.1 -n 100 -l 4201
> We are using sctplib version (19) maj=0, min=19
> *** Sent 6, Received 6 packets
> 1 0 0 0 397 17 4416 4096
> 1 0 0 0 397 17 4416 4096
> *** Sent 1, Received 1 packets
> 1 0 0 0 397 17 1468 2936
> 1 0 0 0 397 17 1468 2936
> . . . . . . . . . . .
> 1 0 0 0 397 17 1468 2936
> 1 0 0 0 397 17 1468 2936
> *** Sent 1, Received 1 packets
> 1 0 0 0 397 17 1468 2936
> 1 0 0 0 397 17 1468 2936
> . . . . . . . . . . .
> 1 0 0 0 397 17 1468 2936
> ......
>
> ----------------------------------------------------------------------------------
>
> >testServer -s 192.168.0.1
> We are using sctplib version (19) maj=0, min=19
> *** Sent 3, Received 4 packets
> 1 0 0 4096 0 0 3000 4096
> *** Sent 3, Received 2 packets
> 1 0 0 4096 0 0 3000 4096
> *** Sent 1, Received 1 packets
> 1 0 0 4096 0 0 3000 4096
> 1 0 0 4096 0 0 3000 4096
> . . . . . . . . . . . . . . .
> 1 0 0 4096 0 0 3000 4096
> 1 0 0 4096 0 0 3000 4096
> *** Sent 1, Received 1 packets
> 1 0 0 4096 0 0 3000 4096
> 1 0 0 4096 0 0 3000 4096
> . . . . . . . . . . . . . . .
>
> Best regards,
> Michael
>
>
> ----- Original Message -----
> From: "Andreas Jungmaier"
> <ajung AT exp-math.uni-essen.de>
> To: "Michael Nikolaev"
> <mvn AT gu.kiev.ua>;
>
> <discussion AT sctp.de>
> Sent: Friday, August 30, 2002 5:43 PM
> Subject: Re: [SCTP-Discussion] Bug in SACK processing
>
>
> > Michael,
> >
> > thanks for the input. I will check that.
> >
> > The idea of having the same chunk pointers in two different
> > lists _IS_ good (provided the C-modules that administrate
> > these two lists have a clear interface for modifications
> > of the chunk data, i.e. the mentioned free() operation).
> >
> > Can you give us a reproducible scenario that triggers
> > the bug you mention ?
> >
> > Best regards,
> > Andreas
> >
> > On 30 Aug 2002 02:58 CEST you wrote:
> >
> > > Hello,
> > >
> > > I guess, there is the following bug in the function rtx_process_sack()
> > > [reltransfer.c].
> > > At the beginning of this function the function rtx_process_sack() is
> > > called that will
> > > FREE() chunk data. Afterwards, at the end of rtx_process_sack() one of
> > > functions
> > > fc_sack_info() or fc_fast_retransmission() will be called that will
> > > call eventually
> > > fc_dequeue_sacked_chunks(). The latter function is scanning fields of
> > > chunk
> > > data that have been previously deleted (from heap) in
> > > rtx_dequeue_up_to().
> > > I think, it is was not very good idea to have the same chunk pointers
> > > in two
> > > different lists.
> > > Best regards,
> > > Michael
> >
> >
>
>
> ЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪщ┼г.╡х╗·f╒√)Ю√+-v+╨к"╒ЛrзЪuХm╤÷ЪЪ
> 0Чг-╖В^Чf╒√f╖ЧX╛╤)ъёВb╠к╛╡*'
>

---

• Re: [SCTP-Discussion] Bug in SACK processing, Michael Nikolaev, 09/01/2002

---

Archive powered by MHonArc 2.6.19+.