Re: recv() clarification in SCTP sockets API draft
"Brian F. G. Bidulock" <bidulock@openss7.org> Thu, 05 August 2010 19:03 UTC
Return-Path: <bidulock@openss7.org>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F9193A6900 for <tsvwg@core3.amsl.com>; Thu, 5 Aug 2010 12:03:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71-Ud6UVdxSw for <tsvwg@core3.amsl.com>; Thu, 5 Aug 2010 12:03:03 -0700 (PDT)
Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 291313A6937 for <tsvwg@ietf.org>; Thu, 5 Aug 2010 12:03:01 -0700 (PDT)
Received: from wilbur.pigworks.openss7.net (IDENT:+XaC7mE4UPtmqofgfShco9OyLJqcQ5Lj@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3+etch1) with ESMTP id o75J3VOT008548; Thu, 5 Aug 2010 13:03:31 -0600
Received: from wilbur.pigworks.openss7.net (IDENT:EjXy4athQwKp5RuYF5x+lRR39j206aY9@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o75J3VDX022354; Thu, 5 Aug 2010 13:03:31 -0600
Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o75J3UsX022353; Thu, 5 Aug 2010 13:03:30 -0600
Date: Thu, 05 Aug 2010 13:03:30 -0600
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Subject: Re: recv() clarification in SCTP sockets API draft
Message-ID: <20100805190330.GA21832@openss7.org>
Mail-Followup-To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>, Randy Stewart <randall@lakerest.net>, tsvwg@ietf.org
References: <4C5318B7.2060204@hp.com> <A51D8ACD861B7E41BFC7FE5C64BE96481167B001@MTLEXVS01.ulticom.com> <BE1B7EEE-0B46-46D6-8C0C-5D15A278560C@lurchi.franken.de> <A51D8ACD861B7E41BFC7FE5C64BE96481167B015@MTLEXVS01.ulticom.com> <348884DC-5F88-47A8-8219-644ED6B336B4@lakerest.net> <20100805065615.GA30908@openss7.org> <CBBCCCC8-BA0F-48C8-B1AD-A0870356B008@lurchi.franken.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CBBCCCC8-BA0F-48C8-B1AD-A0870356B008@lurchi.franken.de>
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-To: <blockme@openss7.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: tsvwg@ietf.org, Randy Stewart <randall@lakerest.net>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: bidulock@openss7.org
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Aug 2010 19:03:06 -0000
Michael,
Michael Tuexen wrote: (Thu, 05 Aug 2010 11:24:05)
> On Aug 5, 2010, at 8:56 AM, Brian F. G. Bidulock wrote:
>
> > Randy, Michael,
> >
> > Was it your intention to deviate from the POSIX behaviour
> > of recv()?
> The problem is that POSIX makes SOCK_SEQPACKET unreliable in
> contrast to SOCK_STREAM. Having the same function (recv())
> for the same protocol behave that differently, seems to be
> wrong to me.
What do you mean? POSIX says:
"SOCK_SEQPACKET
Provides sequenced, reliable, bidirectional,
connection-mode transmission paths for records. A record
can be sent using one or more output operations and
received using one or more input operations, but a single
operation never transfers part of more than one record.
Record boundaries are visible to the received via the
MSG_EOR flag."
SOCK_SEQPACKET is clearly "reliable". What do you mean by
> The problem is that POSIX makes SOCK_SEQPACKET unreliable in
> contrast to SOCK_STREAM.
--brian
--
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/
- recv() clarification in SCTP sockets API draft David Lehmann
- Re: recv() clarification in SCTP sockets API draft Vlad Yasevich
- Re: recv() clarification in SCTP sockets API draft Randy Stewart
- Re: recv() clarification in SCTP sockets API draft Chris Benson
- Re: recv() clarification in SCTP sockets API draft Vlad Yasevich
- RE: recv() clarification in SCTP sockets API draft David Lehmann
- Re: recv() clarification in SCTP sockets API draft Michael Tuexen
- RE: recv() clarification in SCTP sockets API draft David Lehmann
- Re: recv() clarification in SCTP sockets API draft Randy Stewart
- Re: recv() clarification in SCTP sockets API draft Brian F. G. Bidulock
- Re: recv() clarification in SCTP sockets API draft Michael Tuexen
- RE: recv() clarification in SCTP sockets API draft David Lehmann
- Re: recv() clarification in SCTP sockets API draft Michael Tuexen
- Re: recv() clarification in SCTP sockets API draft Brian F. G. Bidulock
- RE: recv() clarification in SCTP sockets API draft David Lehmann
- Re: recv() clarification in SCTP sockets API draft Michael Tuexen
- Re: recv() clarification in SCTP sockets API draft Michael Tuexen
- Re: recv() clarification in SCTP sockets API draft Michael Tuexen
- RE: recv() clarification in SCTP sockets API draft David Lehmann
- RE: recv() clarification in SCTP sockets API draft David Lehmann
- RE: recv() clarification in SCTP sockets API draft Chris Benson
- Re: recv() clarification in SCTP sockets API draft Brian F. G. Bidulock
- Re: recv() clarification in SCTP sockets API draft Michael Tuexen
- Re: recv() clarification in SCTP sockets API draft Michael Tuexen
- Re: recv() clarification in SCTP sockets API draft Michael Tuexen
- Re: recv() clarification in SCTP sockets API draft Brian F. G. Bidulock
- Re: recv() clarification in SCTP sockets API draft Randy Stewart
- Re: recv() clarification in SCTP sockets API draft Michael Tuexen
- RE: recv() clarification in SCTP sockets API draft David Lehmann
- Re: recv() clarification in SCTP sockets API draft Brian F. G. Bidulock
- Re: recv() clarification in SCTP sockets API draft Brian F. G. Bidulock
- Re: recv() clarification in SCTP sockets API draft Randy Stewart
- Re: recv() clarification in SCTP sockets API draft Michael Tuexen
- Re: recv() clarification in SCTP sockets API draft Kacheong Poon
- Re: recv() clarification in SCTP sockets API draft Brian F. G. Bidulock
- RE: recv() clarification in SCTP sockets API draft David Lehmann
- Re: recv() clarification in SCTP sockets API draft Michael Tuexen
- Re: recv() clarification in SCTP sockets API draft Randall Stewart
- Re: recv() clarification in SCTP sockets API draft Brian F. G. Bidulock
- Re: recv() clarification in SCTP sockets API draft Brian F. G. Bidulock
- Re: recv() clarification in SCTP sockets API draft Michael Tuexen
- Re: recv() clarification in SCTP sockets API draft Michael Tuexen