Michael, Thanks for the info...
I dont have any metrics about the improved
performance. I got this stat from Vol 1 of the book you mentioned. viz. "unix
network programming by W Richard Stevens vol 1". Chapter 14 talks abt this
comparision.
The (almost) 2 fold increase in teh speed set me
thinking abt the approach to a more fine tuned IPC.
Any inputs abt the ipv6 testing?!
Thanks,
Regards,
Ajay
----- Original Message -----
From:
Michael Mueller
To: discussion AT sctp.de
Sent: Saturday, November 10, 2001 6:46
PM
Subject: Re: [SCTP-Discussion] Sockets
for IPC: Unix / TCP sockets?
See below
----- 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.
Had to use the IPCS commands to remove lingering queues in
some system malfunction scenarios.
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.
Not a security threat, instead it was a robustness
threat. I imagined some user cleaning out files that were Unix
protocol "addresses". I preferred using INET protocol where disruption
had to be more intentional than inadvertent.
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.
Do you have measurements showing 2X
improvement? I was aware of fractional improvement by Unix over Inet
protocl for UDP. 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.
I chose using Inet protocol throughout to simplify
the code. If I am operating at the edge of performance, I would rather
boost hardware performance than start tuning software. If tuning is
necessary, it should be done after a time study is done, and then critical
regions of code should be coded in ASM. 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+.