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

Text archives Help


Re: [SCTP-Discussion] Sockets for IPC: Unix / TCP sockets?


Chronological Thread 
  • From: "Michael Mueller" <bhu5nji AT yahoo.com>
  • To: <discussion AT sctp.de>
  • Subject: Re: [SCTP-Discussion] Sockets for IPC: Unix / TCP sockets?
  • Date: Mon Nov 12 14:57:02 2001
  • List-id: SCTP Discussions <discussion.sctp.de>
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
 
 
 
----- Original Message -----
From: Michael Mueller
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
 
 
-----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
 

Archive powered by MHonArc 2.6.19+.

Top of page