Chronological Thread 

< Chronological >      < Thread >

---

Hi Julio,

understand the example I gave you below. It is a problem on the
receiver side. Fixing it needs a modification to the stream engine,
which is one of the more complex parts of the implementation.

Best regards
Michael

On Oct 14, 2006, at 11:19 PM, Julio Kriger wrote:

Hi Michael!
I looked into the code and I saw that the message is fragmented in small pieces and put on queue to transfered. But didn't found the part that you talk about, the association being stalled.
How hard could it be fix this?
Regards,
Julio



On 10/14/06, Michael Tuexen <Michael.Tuexen AT micmac.franken.de> wrote: Hi Julio,

yes this is correct. But when the message is larger than the
announced receiver window of the
receiver the association will just stop transferring data. This is
because there is no
partial delivery API.

If the receiver announces 64K, but the user on the sender side passes
a 128K message, it
will be fragmented and the first 64 K will be transferred. Then the
receiver has no more
space but also can not free space because it can not deliver the
incomplete message. So
the association is stalled.

The solution is to deliver the message in parts on the receiver side.
But this is not
implemented.

Best regards
Michael

On Oct 13, 2006, at 2:41 PM, Julio Kriger wrote:

> Hi Michael!
> Correct me I get it wrong, but I understand that I can send a
> message of any length, and internaly sctplib cut the message on
> parts (or chuncks) that are deliverables to the sender. I
> understand that this parts or chuncks fit on a raw socket, are sent
> to the receiver and later all parts or chuncks are put together to
> obtain the original (any length) message.
> I will try to look for this bug you say, and tell what I found.
> Regards,
> Julio
>
>
>
> On 10/13/06, Michael Tuexen <
Michael.Tuexen AT micmac.franken.de>
> wrote:I'm not aware of a limit on the sender side, so this most
> likely is a
> bug. However,
> since the sctplib does not implement a partial delivery API, the
> longest message
> you can transfer is about the size of the receiver window. This
> basically depends
> to the receive buffer space for raw sockets and is about 20-64 KByte
> on BSD systems.
> Way smaller then a MB...
>
> Best regards
> Michael
>
> On Oct 12, 2006, at 6:17 PM, Julio Kriger wrote:
>
> > Hi!
> > What is the maximum message length the SCTP_send function accept?
> > I'm trying it with 4 threads sending 1MB message each, and it
> freeze.
> >
> > Also I get the following error message:
> >
> > AF_INET : sendto()=-1 !
> >
> > what do this mean? TIA
> >
> > Regards,
> > Julio
> >
> > --
> > --
> > From the moment I picked your book up until I laid it down, I was
> > convulsed with laughter. Someday I intend reading it.
> > Groucho Marx
> > ----------------------------
> > Julio Kriger
> >
mailto:juliokriger AT gmail.com
>
>
>
>
> --
> --
> From the moment I picked your book up until I laid it down, I was
> convulsed with laughter. Someday I intend reading it.
> Groucho Marx
> ----------------------------
> Julio Kriger
>
mailto:juliokriger AT gmail.com




--
--
From the moment I picked your book up until I laid it down, I was convulsed with laughter. Someday I intend reading it.
Groucho Marx
----------------------------
Julio Kriger
mailto:juliokriger AT gmail.com

---

• [SCTP-Discussion] max length of a single message, Julio Kriger, 10/12/2006
  • Re: [SCTP-Discussion] max length of a single message, Michael Tuexen, 10/13/2006
    • Re: [SCTP-Discussion] max length of a single message, Julio Kriger, 10/13/2006
      • Re: [SCTP-Discussion] max length of a single message, Michael Tuexen, 10/14/2006
        • Re: [SCTP-Discussion] max length of a single message, Julio Kriger, 10/14/2006
          • Re: [SCTP-Discussion] max length of a single message, Michael Tuexen, 10/15/2006

---

Archive powered by MHonArc 2.6.19+.