On Sat, 30 June 2001, Risto J�rvinen wrote:

> 
> Hi,
> 
> Have you considered using unix domain sockets for client-server
> communications?

I have been planning to implement domain sockets all along, just haven't got around to 
it.
What I'll (eventually?) get around to doing is modularizing the network code. Just 
like video an input now, a network driver would send and recieve packets. There could 
be drivers for TCP/IP, unix sockets, linking the client and server into one binary, or 
even serial ports. The client would try all installed network modules in predefined 
order to connect at the fastest possible speed, and the server could listen on 
multiple drivers.

> 
> When both client and server reside in the same computer unix sockets
> should be more efficient than internet sockets.  Especially in the
> embedded environments where you might want to conserve memory by removing
> tcp/ip support from kernel.  Differences between using internet sockets
> and unix sockets are minimal.  Instead of IP numbers and ports, unix
> sockets use paths.

Yes. Also, TCP/IP has more latency than unix sockets. Even over the loopback device, 
it's slower than unix sockets.

> 
> Rather than to ponder it's usability on a theoretical level, I made a
> small patch that switches cli_c and pgserver to unix domain sockets.  TCP
> portions are #ifdef'ed out, uclinux-parts probably broken.  Unified diff
> is attached to this email.

It's in CVS now. On the server I changed the ifdef constant to CONFIG_UNIX_SOCKET and 
added an entry to the configuration menu.
On the client the constant is also CONFIG_UNIX_SOCKET. There should probably be a 
command line option for 'configure' to enable it, but I don't know how to do that 
now... (Ask the build system expert :)

> 
> If thought usable, unix sockets should be put as a config option and
> server address parameter definition should be cleaned out.  (and someone
> fix uclinux-portions too.)
> 
> 
>  - Riba

--
To the systems programmer, users and applications serve only to provide a 
test load.


_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/pgui-devel

Reply via email to