I recommend "Unix Network Programming Volume 2,
Interprocess Communications" by W. Richard Stevens. An expensive but
worthwhile investment as are all of the books by Stevens.
http://www.kohala.com/
----- Original Message -----
From:
Ajay
Nambi
To: discussion AT sctp.de
Sent: Monday, November 12, 2001 6:20
AM
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
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+.