Re: Non-blocking open-network-stream

[Kim F. Storm]

Helmut Eller <address@hidden> writes:

> address@hidden (Kim F. Storm) writes:
> 
> > (do we have papers for that?)
> 
> No.  If needed, I will sign papers.
> 
> > However, I think it can be done via open-network-stream:
> > 
> > If the HOST argument is nil, a server socket is opened which
> > accepts connections.  The sentinel is called - with a newly
> > created process - whenever a connections is accepted.
> 
> I see several problems with this approach:
> 
>  - What is the process-name for the connections?  The same as for the
>    server socket?  All connections with the same name?

My idea is to name it as the server process concatenated with the
ip address and source port of the client, i.e. something like

        "service <10.20.30.40:3248>"

I prefer this to manually having to give each connection a unique name
in advance (as would be necessary with your accept-connection API).

> 
>  - How do you open a Unix server socket?  
> 

I intent do rename the NON-BLOCKING argument to a more generic TYPE
argument.  Eventually, it could be things like:

If HOST specified - connect to that host:

nil - blocking connect (tcp) to SERVICE on HOST
t   - non-blocking connect (tcp) to SERVICE on HOST
udp - open udp socket with target SERVICE on HOST
unix - connect to unix socket on address SERVICE

If HOST is nil - open a server socket:

nil - open tcp socket listning on SERVICE port
t   - same as nil
udp - open udp socket bound to SERVICE port
unix - open unix socket bound to address SERVICE

>  - It's possible to open Unix server sockets.  It would be reasonable
>    to support Unix client sockets too.  How can this be done?
> 

See above.  (IIRC, Your patch didn't cover unix sockets)

>  - What should NON-BLOCKING mean for server sockets?

See above.

> 
>  - open-network-stream takes already 7 arguments.  Putting even more
>    functionality in makes it hard to document.

I don't agree.  Renaming NON-BLOCKING to TYPE and switching on
whether HOST is non-nil (connect) or nil (start server) seems
fairly clean and simple to me.

> 
> Server sockets are IMHO different enough to merit a separate
> function.  What is the advantage of merging those concepts?
> 

Most of the necessary functionality is already in open-network-stream,
so adding the server part there is pretty orthogonal I think.

-- 
Kim F. Storm <address@hidden> http://www.cua.dk