Chronological Thread 

< Chronological >      < Thread >

---

Hi Folks,

Andreas blamed me for this sting-interface, so let me explain the reasons why
I favoured it:

1) If the ULP uses the sockunion, it has to use OS-specific headerfiles
(e.g. inet.h, in.h, socket.h), although it has no direct socket interface.
This causes problems if you want to compile on different OSes and targets.

2) The string-conversion is only necessary for the few administation
functions (registerInstance(), associate() ), not for message passing! So the
performance of the SCTP-API is not involved. Please take this into account!

Here it is the (additional) UDP-Interface for administation purpose, which
may cause the performance problems.

3) When I started with this SCTP-stuff I was annoyed of learning such a
complicated structure like 'sockunion' just to pass only one integer for the
IPv4-address! I am sure that the most of you are familiar with this stuff,
but I wanted to prevent other ULP-developers of learning that.

Here I show you the record I made just to unterstand the sockunion - maybe
then you understand better my problems with this structure:


//*************
// Daten
//*************
#include "globals.h"
union sockunion
{
struct sockaddr sa;
struct sockaddr_in sin;
#ifdef HAVE_IPV6
struct sockaddr_in6 sin6;
#endif /* HAVE_IPV6 */
};


#include <arpa/inet.h>
/* Convert Internet host address from numbers-and-dots notation in CP
into binary data in network byte order. */

extern u_int32_t inet_addr __P ((__const char *__cp));

#include <stdint.h>
/* Unsigned. */
typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;
typedef unsigned int uint32_t;
#if __WORDSIZE == 64
typedef unsigned long int uint64_t;
#else
__extension__
typedef unsigned long long int uint64_t;
#endif

#include <netinet/in.h>

/* Structure describing an Internet socket address. */
struct sockaddr_in
{
__SOCKADDR_COMMON (sin_);
uint16_t sin_port; /* Port number. */
struct in_addr sin_addr; /* Internet address. */

/* Pad to size of `struct sockaddr'. */
unsigned char sin_zero[sizeof (struct sockaddr) -
__SOCKADDR_COMMON_SIZE -
sizeof (uint16_t) -
sizeof (struct in_addr)];
};


/* Internet address. */
struct in_addr
{
uint32_t s_addr;
};



#include <bits/socket.h>

/* Structure describing a generic socket address. */
struct sockaddr
{
__SOCKADDR_COMMON (sa_); /* Common data: address family and length. */
char sa_data[14]; /* Address data. */
};


/* Address families. */
#define AF_UNSPEC PF_UNSPEC
#define AF_LOCAL PF_LOCAL
#define AF_UNIX PF_UNIX
#define AF_FILE PF_FILE
#define AF_INET PF_INET
#define AF_AX25 PF_AX25
#define AF_IPX PF_IPX
#define AF_APPLETALK PF_APPLETALK
#define AF_NETROM PF_NETROM
#define AF_BRIDGE PF_BRIDGE
#define AF_ATMPVC PF_ATMPVC
#define AF_X25 PF_X25
#define AF_INET6 PF_INET6



/* Protocol families. */
#define PF_UNSPEC 0 /* Unspecified. */
#define PF_LOCAL 1 /* Local to host (pipes and file-domain). */
#define PF_UNIX PF_LOCAL /* Old BSD name for PF_LOCAL. */
#define PF_FILE PF_LOCAL /* Another non-standard name for PF_LOCAL.
*/
#define PF_INET 2 /* IP protocol family. */
#define PF_AX25 3 /* Amateur Radio AX.25. */
#define PF_IPX 4 /* Novell Internet Protocol. */
#define PF_APPLETALK 5 /* Appletalk DDP. */
#define PF_NETROM 6 /* Amateur radio NetROM. */
#define PF_BRIDGE 7 /* Multiprotocol bridge. */
#define PF_ATMPVC 8 /* ATM PVCs. */
#define PF_X25 9 /* Reserved for X.25 project. */
#define PF_INET6 10 /* IP version 6. */
#define PF_ROSE 11 /* Amateur Radio X.25 PLP. */


#include <bits/sockaddr.h>

/* POSIX.1g specifies this type name for the `sa_family' member. */

typedef unsigned short int sa_family_t;

/* This macro is used to declare the initial common members
of the data types used for socket addresses, `struct sockaddr',
`struct sockaddr_in', `struct sockaddr_un', etc. */

#define __SOCKADDR_COMMON(sa_prefix) \
sa_family_t sa_prefix##family



Viele Gruesse
Wolfgang Schruefer

**************************************
Wolfgang Schrüfer SIEMENS AG
ICN WN CC EKJ 14 TEL: +49 89 722-61646
mailto:Wolfgang.Schruefer AT icn.siemens.de
**************************************

> -----Ursprüngliche Nachricht-----
> Von: Marc Boucher
> [SMTP:marc+sctp AT mbsi.ca]
> Gesendet am: Donnerstag, 5. April 2001 12:08
> An:
> discussion AT sctp.de
> Betreff: Re: [SCTP-Discussion] Is the timer_list initialised?
>
> On Thu, Apr 05, 2001 at 11:48:47AM +0200, Andreas Jungmaier wrote:
> > > > > As that should not happen very often I don't think it
> > > > > is a performance problem.
> > >
> > > Really?
> > > For each UDP and SCTP packet received, the sockunion is converted to a
> > > string, (see adl_sockunion2str() calls in adaptation.c:dispatch_event())
> > > which would have to be eventually reparsed by the callback.
> > > This is unnecessary overhead.
> >
> > Well, I have not only looked at your patches but also read
> > your comments :-)
> > In the current version of the code I have changed at least the
> > SCTP thing - it does not do the conversion twice now.
> >
> > > > I prefer having predefined structs.
> > >
> > > So do I. IMHO passing string-encoded addresses, especially in callbacks,
> > > isn't a good idea.
> >
> > And so do I, of course. That was why we initially passed sockunions.
> > I did not like the idea of strings, either at first - but Siemens
> > gets what Siemens wants :-)
>
> Well believe it or not, my SCTP related work is also mandated by Siemens!
> And on the embedded system where they use the library (a 50mhz MPC860 board)
> repetitive string manipulations are a non-negligible waste of CPU resources.
>
> > And there were surprisingly few comments about the API, when we
> > discussed it before - well except for some of the Siemens developers,
> > notably Wolfgang Schrüfer who had some very good remarks.
>
> Unfortunately I was too busy at the time to follow and participate in
> those discussions, but they surely lead to many good improvements.
>
> However the usage of strings when processing packets leaves to be desired..
>
> Gruss
> Marc
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion

---

• AW: [SCTP-Discussion] Is the timer_list initialised?, Schruefer Wolfgang, 04/03/2001
  • Re: AW: [SCTP-Discussion] Is the timer_list initialised?, Andreas Jungmaier, 04/03/2001
  • <Possible follow-up(s)>
  • AW: [SCTP-Discussion] Is the timer_list initialised?, Schruefer Wolfgang, 04/05/2001
  • AW: [SCTP-Discussion] Is the timer_list initialised?, Schruefer Wolfgang, 04/05/2001
    • [SCTP-Discussion] Strings vs. Sockunion (was: Is the timer_list initialised?), Andreas Jungmaier, 04/05/2001
      • Re: [SCTP-Discussion] Strings vs. Sockunion (was: Is the timer_list initialised?), Marc Boucher, 04/05/2001
        • Re(2): [SCTP-Discussion] Strings vs. Sockunion (was: Is the timer_list initialised?), Michael Tüxen, 04/05/2001
          • Re: Re(2): [SCTP-Discussion] Strings vs. Sockunion (was: Is the timer_list initialised?), Marc Boucher, 04/06/2001
            • Re(4): [SCTP-Discussion] Strings vs. Sockunion (was: Is the timer_list initialised?), Michael Tüxen, 04/06/2001
              • Re: Re(4): [SCTP-Discussion] Strings vs. Sockunion (was: Is the timer_list initialised?), Marc Boucher, 04/06/2001
              • Re(6): [SCTP-Discussion] Strings vs. Sockunion (was: Is the timer_list initialised?), Michael Tüxen, 04/06/2001

---

Archive powered by MHonArc 2.6.19+.