Chronological Thread 

< Chronological >      < Thread >

---

We are testing the IPv6 stuff, but only on a testnet. Two computers connected.
Do you experience any problems regarding IPv6?

Best regards
Michael

Michael Tuexen Tel.: +49 89 722 47210
Siemens AG Fax: +49 89 722 48212
ICN WN CS SE 5 E-mail:
Michael.Tuexen AT icn.siemens.de

> -----Original Message-----
> From: Ajay Nambi
> [SMTP:ajay.nambi AT wipro.com]
> Sent: Monday, November 12, 2001 12:20 PM
> To:
> discussion AT sctp.de
> Subject: [SCTP-Discussion] Sockets for IPC: Unix / TCP sockets?
>
> Hi,
> This is an old thread that i am replying to. I had 2 queries
>
> Query1
> -----------
>
> >>There might be some inefficiencies arising from using UDP and INET
> >>protocol for IPC, but memory and >>processors are cheaper than
> >>maintaining multiple methods of accomplishing the same goal.
>
>
> >>The System V IPC had some lingering side-effects that had to be manually
> >>cleaned in the event of >>system malfunction.
>
> Can you pls elucidate what this would be?
>
> >>The UDP with Unix protocol required using filenames as addresses. The
> >>exposure of filenames to users >>was a small but unneeded risk to
> >>operational safety
>
> Can you pls let me know abt the extent of risk and security threat that
> exists due to this 'access' to file name.
>
> Since the Unix domain of sockets are intended for IPC between processes on
> the same host & Berkeley derived implementations of the unix sockets are
> twice as fast as tcp sockets(i'm not certain abt system V, but i guess it
> should be on par with BSD), using these can improve the performance.
>
> Considering the above points, if i were to weigh the 'processor power and
> memory' & 'side effects & security', which would be a better choice of
> sockets? UNIX domain OR INET domain sockets.
>
>
> Query2
> -----------
> And, has pre14 been tested in an actual IPv6 network (as a directly part of
> 6bone or through IPv4 tunnelling !?!?) including multihoming with multiple
> IPv6 interfaces?
>
>
>
> Kindly comment on these issues..
> Regards,
> Ajay
>
>
>
>
> ----- Original Message -----
> From: Michael Mueller
> <mailto:bhu5nji AT yahoo.com>
>
> To:
> discussion AT sctp.de
>
> <mailto:discussion AT sctp.de>
>
> Sent: Friday, October 12, 2001 7:25 PM
> Subject: Re: [SCTP-Discussion] Why Udp as the IPC mechanism?
>
> I would like to support the decision to use UDP for IPC. My support
> is the result of using three different forms of IPC in my application:
> System V IPC, Unix protocol UDP, and Internet Protocol UDP. Since INET
> protocol is used elsewhere in my application, the alignment of IPC to the
> INET protocol seemed a natural choice. There might be some inefficiencies
> arising from using UDP and INET protocol for IPC, but memory and processors
> are cheaper than maintaining multiple methods of accomplishing the same
> goal. The System V IPC had some lingering side-effects that had to be
> manually cleaned in the event of system malfunction. The UDP with Unix
> protocol required using filenames as addresses. The exposure of filenames
> to users was a small but unneeded risk to operational safety. Using UDP
> with INET protocol provided determinism in specifying address/port without
> divulging this information to system users. There is some risk of another
> program using my address/port, but I w!
!
ill be able to manage that risk.
>
> For completeness, I might add that UDP is a worthy choice since it is
> a datagram protocol as is SCTP (ignoring for the moment that S in SCTP
> stands for Stream).
>
> Just my two euros worth of opinion.
> Mike
>
> ----- Original Message -----
> From: Sim Woon Chiat ICM CA MS MI E7 Extern
> <mailto:WoonChiat.Sim.extern AT icn.siemens.de>
>
> To:
> 'discussion AT sctp.de'
>
> <mailto:'discussion AT sctp.de'>
>
> Sent: Friday, October 12, 2001 5:09 AM
> Subject: RE: [SCTP-Discussion] Why Udp as the IPC mechanism?
>
> Hi,
>
> firstly, i am making the assumption that you are referring to
> using UDP as a IPC for the daemon, and i'm answering with that in mind.>
> (i don't want to get into a debate into the various pros and
> cons of each IPC mechanisms. there are people more qualified for that..)
>
> when the daemon was first started, the sctp library only
> supported registering UDP callbacks with its event loop, and that was the
> easiest way forward to get things going. Using other form of IPC means
> finding a way to integrate them with the event loop of the sctp library. It
> was method that i was comfortable with and in truth, no REAL comparsion of
> the merits of each methods of IPC was done. that is of course not to say
> that a review may not be needed. (but i won't be doing that now as my
> concern now is mainly in maintaining the state integrity of the daemon)
>
> of course, proposed alternative (preferably in the form of
> source code) is most welcome.
>
> cheers
> wc
>
>
>
> -----Original Message-----
> From: Ajay Nambi
> [mailto:ajay.nambi AT wipro.com]
> Sent: Friday, October 12, 2001 5:46 AM
> To:
> discussion AT sctp.de
> Subject: [SCTP-Discussion] Why Udp as the IPC
> mechanism?
>
>
> Hi,
>
> I wanted to know if there was any particular
> reason UDP was chosen as the means for IPC. Wouldn't using 'shared memory'
> be more faster?
>
> Is there any big advantage in using UDP, compared
> to using 'shared memory' & 'Queues'?
>
> Can anybody shed some light in this aspect?
>
> Thanks in advance,
> Regards,
> Ajay
>
> << File: Wipro_Disclaimer.txt >>

---

• [SCTP-Discussion] Sockets for IPC: Unix / TCP sockets?, Ajay Nambi, 11/12/2001
  • Re: [SCTP-Discussion] Sockets for IPC: Unix / TCP sockets?, Michael Mueller, 11/12/2001
    • Re: [SCTP-Discussion] Sockets for IPC: Unix / TCP sockets?, Ajay Nambi, 11/12/2001
  • Re: [SCTP-Discussion] Sockets for IPC: Unix / TCP sockets?, Michael Mueller, 11/12/2001
  • <Possible follow-up(s)>
  • RE: [SCTP-Discussion] Sockets for IPC: Unix / TCP sockets?, Tuexen Michael, 11/13/2001
    • Re: [SCTP-Discussion] Sockets for IPC: Unix / TCP sockets?, Ajay Nambi, 11/15/2001
  • RE: [SCTP-Discussion] Sockets for IPC: Unix / TCP sockets?, Tuexen Michael, 11/15/2001

---

Archive powered by MHonArc 2.6.19+.