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

Text archives Help


Re(2): [SCTP-Discussion] Strings vs. Sockunion (was: Is the timer_list initialised?)


Chronological Thread 
  • From: Michael Tüxen <Michael.Tuexen AT micmac.franken.de>
  • To: <discussion AT sctp.de>
  • Subject: Re(2): [SCTP-Discussion] Strings vs. Sockunion (was: Is the timer_list initialised?)
  • Date: Thu Apr 5 21:46:00 2001
  • List-id: SCTP Discussions <discussion.sctp.de>
Dear Andreas, Marc, Wolfgang and all others,

I think I'm a bit lost. Let me fisrt clarify some things:

We are developing a prototype of SCTP. So I think technical
arguments should count! I do not like arguments like 'Siemens
gets what Siemens wants'. This might be acceptable for product
development, but as I told you we (Andreas and myself) are not
developing SCTP for a product.
If you need something for a Siemens-product, please contact Wolfgang.

This does not mean that we are alone. We try to coordinate our
stuff as much as possible with Wolfgang, because he is using our
code as a base and he is a professional developer, which I am not.
So his experience is important. Other developers are also using our
code for prototyping.

So there will be NO change in the API before mid of May, because
there are two baaaaaaaakeoffs which will use our code and therefore
it has to be stable. We are currently working an debugging and preparing
the implementation for the bakeoff. That is the only thing we will work
on until mid of may.

So coming back to the discussion, I think have two choices:

1. Using a sochunion-like structure and proving routines str2sockunion
and vice versa. Then for the function sctp_registerInstance and
sctp_associate you would call these funcitons and use the result in
these functions.

2. Using a string type and the functions sctp_registerInstance
and sctp_associate call these translation function themselves.

>From a performance point of view I do not see a difference. But the
API for 2. is simpler: You need two functions in the API less and no sockunion
structure. This is the argument Wolfgang stated and which is valid, I
think. I especially do NOT see a performance difference!

So why using the other solution?

Best regards
Michael

--
e-mail:
Michael.Tuexen AT micmac.franken.de

On Thu, Apr 5, 2001, Marc Boucher
<marc+sctp AT mbsi.ca>
wrote:

>Andreas, I am in full agreement with your comments.
>
>Thanks
>Marc
>(on behalf of Siemens ICM N MR GE DC1)
>
>On Thu, Apr 05, 2001 at 06:47:17PM +0200, Andreas Jungmaier wrote:
>> -----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
>>
>_______________________________________________
>discussion mailing list
>discussion AT sctp.de
>http://www.sctp.de/mailman/listinfo/discussion




Archive powered by MHonArc 2.6.19+.

Top of page