SCTP Discussions

Text archives Help


AW: [SCTP-Discussion] Strings vs. Sockunion (was: Is the timer_li st initialised?)


Chronological Thread 
  • From: Schruefer Wolfgang <Wolfgang.Schruefer AT icn.siemens.de>
  • To: "'discussion AT sctp.de'" <discussion AT sctp.de>
  • Subject: AW: [SCTP-Discussion] Strings vs. Sockunion (was: Is the timer_li st initialised?)
  • Date: Fri Apr 6 11:02:01 2001
  • List-id: SCTP Discussions <discussion.sctp.de>

Hello Andreas and all,

there are two things you should consider about the Windows portability.

1) Even the line "#include <winsock2.h>" is a portability mismatch.

2) "sockaddr_in" sounds similar, but is indeed different for Windows and
UNIX:

Example to provide the IP-Address:

WINDOWS:
su->sin.sin_addr.S_un.S_addr = inet_addr(str);

UNIX:
su->sin.sin_addr.s_addr = inet_addr(str);


Wolfgang

> -----Urspr> üngliche Nachricht-----
> Von: Andreas Jungmaier
> [SMTP:ajung AT exp-math.uni-essen.de]
> Gesendet am: Donnerstag, 5. April 2001 18:47
> An:
> discussion AT sctp.de
> Betreff: [SCTP-Discussion] Strings vs. Sockunion (was: Is the
> timer_list initialised?)
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello all,
>
> please see my comments below....
>
> > At least I would like a portability between UNIX and Windows.
> > But I'm afraid that the sockaddr_in is different (please correct me if I'm
> > wrong). ASCII format (or char[]) will work everywhere.
> >
>
> winsock.h does provide
>
> struct sockaddr
> struct sockaddr_in
>
> so that should not be the problem.
>
>
> > > > let's not reinvent the wheel
> > >
> > > Even though it didn't sound like it, I actually agree with you and don't
> > > like the idea of passing addresses around as ascii data. I'm just
> > > trying
> > > to understand the portability requirements of this interface.
> > >
> > > If the interface is to be slightly less portable, but more familiar to
> > > most, then it should probably rely on some of the popular standardized
> > > data types. Personally, I'm happy with func(sockaddr *addr, int
> > > addr_len)
> > > where addr points to either a sockaddr_in or sockaddr_in6. This would
> > > also seem to be in line with the sctp socket draft standard. As for the
> > > other data types used by the interface, it would seem reasonable to
> > > assume the POSIX 1003.1g definitions for intN_t, uintN_t, size_t, etc.
> > >
> > > What are the portability requirements of this interface?
>
> I think the way to eventually go will be back to what I had
> before - a union of sockaddr, sockaddr_in, and maybe sockaddr_in6.
> After all that does not cause any portability problems at all
> (it is a plain C union :-)
>
> But please let me repeat: unless there should be a majority of the
> Siemens M3UA developers supporting that change, I will not do so
> until after the the SCTP and M3UA bakeoffs.
>
> Best regards,
>
> Andreas Jungmaier
>
> -
> ----------------------------------------------------------------------------
> void hamlet()
> {#define question=((bb)||(!bb))}
> -
> ----------------------------------------------------------------------------
> Andreas Jungmaier, Dipl.-Ing.
> University of Essen email:
> ajung AT exp-math.uni-essen.de
> Computer Networking Technology Group Tel. : +49 (0201) 183-7636
> -
> ----------------------------------------------------------------------------
> PGP Public Key and Fingerprint: see http://www.exp-math.uni-essen.de/~ajung
> -
> ----------------------------------------------------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE6zKGcd2Uw+xBvGUIRApDpAJoC+YeB828LPqVNe763i7fTJdwRzQCfY1Gm
> NHxTphPy+PLm8rpI6ccP6zU=
> =FGlQ
> -----END PGP SIGNATURE-----
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion




Archive powered by MHonArc 2.6.19+.

Top of page