First login?
Lost password?
 
 
sctp-discussion AT lists.franken.de 
SCTP Discussions

Text archives Help


RE: [SCTP-Discussion] Is the timer_list initialised?


Chronological Thread 
  • From: "Wagner, Joel" <Joel.Wagner AT icn.siemens.com>
  • To: "'discussion AT sctp.de'" <discussion AT sctp.de>
  • Subject: RE: [SCTP-Discussion] Is the timer_list initialised?
  • Date: Thu Apr 5 14:17:01 2001
  • List-id: SCTP Discussions <discussion.sctp.de>
How about a compromise? Use a struct that contains the IP address as it is
represented on the net. This would: a) keep conversions to a minimum, b)
work equally well for IPv4 and IPv6, c) make it easy to translate to/from
various target required structs such as sockaddr_in, sockunion, etc.

The struct could look something like:

typedef struct {
char ipa_bytes[IPA_MAX_ADDR_SIZE];
int ipa_length;
} IPaddress;



> -----Original Message-----
> From: Schruefer Wolfgang
> [mailto:Wolfgang.Schruefer AT icn.siemens.de]
> Sent: Thursday, April 05, 2001 7:19 AM
> To:
> 'discussion AT sctp.de'
> Subject: AW: [SCTP-Discussion] Is the timer_list initialised?
>
>
> 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
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion
>


Archive powered by MHonArc 2.6.19+.

Top of page