- From: "Brian F. G. Bidulock" <bidulock AT openss7.org>
- To: Michael Tuexen <Michael.Tuexen AT micmac.franken.de>
- Cc: discussion AT sctp.de, Hideki Kishida <kishida AT secnet.co.jp>
- Subject: Re: [SCTP-Discussion] fragment and reassemble
- Date: Fri Mar 15 10:22:00 2002
- Dsn-notification-to: <bidulock AT openss7.org>
- List-id: SCTP Discussions <discussion.sctp.de>
- Organization: http://www.openss7.org/
Michael,
On Fri, 15 Mar 2002, Michael Tuexen wrote:
>
Hideki,
>
>
you are wrong. SCTP_MAXIMUM_DATA_LENGTH is a constant in
>
sctp.h which should not be changed by the user. It is the
>
maximum data chunk length which fits in an ethernet frame with
>
a common header and a small SACK chunk.
Wouldn't that be somewhat larger than 1400?
--brian
>
>
You should never anything in scyp.h
>
>
Segmentation and reassembly work out of the box. See programs/echo-tool.c
>
for an example. Just use large buffers in the sctp_send and provide
>
large buffers in the sctp_receive calls.
>
>
Best regards
>
Michael
>
>
On Friday, March 15, 2002, at 09:10 AM, Hideki Kishida wrote:
>
>
> Dear all,
>
>
>
> Question to user-data fragmentation and reassmenble:
>
>
>
> #define SCTP_MAXIMUM_DATA_LENGTH 1400
>
> change to
>
> #define SCTP_MAXIMUM_DATA_LENGTH 8000
>
>
>
> In this case, as for sctplib can it send and receive the user-data
>
> of 8000 octets correctly?
>
>
>
>
>
> regards,
>
> Hideki (Japan)
>
>
>
> _______________________________________________
>
> discussion mailing list
>
> discussion AT sctp.de
>
> http://www.sctp.de/mailman/listinfo/discussion
>
>
>
>
>
Michael.Tuexen AT micmac.franken.de
>
>
_______________________________________________
>
discussion mailing list
>
discussion AT sctp.de
>
http://www.sctp.de/mailman/listinfo/discussion
--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
bidulock AT openss7.org
¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦
Archive powered by MHonArc 2.6.19+.