[ds6-devel] Re: new refactor code

[Chris Leishman]

On Monday, January 13, 2003, at 02:58 PM, Mauro Tortonesi wrote:
<snip>
> setup_{local,remote}_streams are really not needed. their inclusion,
> however, makes the code more readable as it splits connection_main in
> smaller and easier-to-read-and-understand blocks. as you said,
> setup_local_stream will also be useful for --exec.

No prob.  I'll put them in.

> yes, but what if we move socktype in connection_attributes? after all 
> the
> family and protocol member of connection_attributes are initialized in
> parse_arguments and used only in ca_to_addrinfo, and both of these
> functions make the following assumptions:
>
> protocol udp <==> socktype dgram
> protocol tcp <==> socktype stream
>
> so, adding a socktype member to connection_attrs could be a good 
> solution.

Actually - there's no benefit from having the socktype in 
connection_attributes unless we want to allow the user to control the 
socket type, which we don't really (they set the family and protocol).

The fact that ca_to_addrinfo has to make that assumption for udp & tcp 
is a hack - because some early getaddrinfo implementations don't 
understand the protocol field properly.

In either case, we must use the socket type returned from getaddrinfo 
(which was used to create the socket).  And since the 
connection_attributes isn't (and shouldn't) be modifying 
connection_attributes, we can't achieve this.

<snip>
>> Of course, we could get really radical and just throw out the socktype
>> type from the io_stream all together....  At the moment it's only used
>> for calling cb_read v's cb_recv - and on connected UDP sockets we can
>> actually use cb_read as well.....so there's no need to differentiate.
>
> mmmmh, what's your opinion about this? does it hurt portability? i
> remember that nc used read/write on udp sockets and that it was really 
> a
> mess...

Actually, it's very portable AFAIK.  The old netcat did the same thing.
I've been tempted to do it for ages.

<snip>
> but there is already __a lot__ of verbose code in do_{connect,listen}.
> adding a few more lines is not really a problem (instead, it would be a
> consistent development behaviour).

*shrug*  Like I said, I'm not overly fussy either way - so I'll move it 
back.

> however we should try to move non-networking code out of do_connect and
> do_listen.

Yeah...we'll I'm not sure what is left in there other than the logging 
of errors, etc.  I'm not too sure how we can move that out and still 
keep it legible (the only solution I can think of is to add error codes 
and strings for the failures and probably some sort of callback for 
non-fatal messages...which is all just too much effort).

Regards,
Chris