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
To: 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 will 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
To: '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
|
Archive powered by MHonArc 2.6.19+.