default tcp host

[Ralf Habacker]

Daniel P. Berrange schrieb:
> On Wed, Jun 20, 2007 at 12:46:00PM -0400, Havoc Pennington wrote:
>   
<snip>
>> DBusString is preferred to any manual string manipulation, basically 
>> char* is only used for "immutable-ish" strings (precision guidelines r 
>> us!). The codebase avoids most of string.h to minimize that category of 
>> security (and crash) bugs. (For read-only use, you can quickly init a 
>> DBusString with an existing char* with _dbus_string_init_const())
>>     
>
> The reason I used a pre-allocated char * is because that's what the 
> getnameinfo() contract requires when resolving the port from a 
> sockaddr_storage  struct. So while I could pass in a DBusString to
> the method, I'll eventually need to use a pre-allocated char * for
> the impl.
>
>   
>> Since listen_tcp_socket / connect_tcp_socket are fairly complex now, it 
>> may be worth thinking about how some of the logic can be moved 
>> cross-platform so it doesn't have to be synced to Windows, though feel 
>> free to punt on that and we'll figure it out later. I don't want to do 
>> it if it results in a big mess, and I can't really think of a good 
>> non-big-mess way to deal with this. Once there is a Windows 
>> implementation it might be easier to see how much of it is common to the 
>> platforms.
>>     
>
> I was looking at the existing Windows impl of the listen/connect methods
> and they in fact seem to have two completely separate implementations of
> each method toggled on #ifdef ENABLE_DBUSSOCKET  which AFAICT is never
> enabled in the codebase.
>   
We had just disabled the DBusSocket code but leaved it in the source for
compatibility.
Only the code where ENABLE_DUSSOCKET is not defined is relevant. 
> Windows has getaddrinfo/getnameinfo, so it ought to be possible to have
> an almost 100% unified impl, with just a few inline #ifdef's to deal
> with way Windows handles errno with its sockets code. 
not to forget the EWOULDSOCKET return code from recv() when using non
blocking sockets, which need special handling.
> That all said I have zero Windows machines, so while I can provide some code as a
> staring point, I'm unable to compile/debug Windows.
>   
We have windows machines for compiling/debugging which makes it able to
fix compile errors. Debugging will be possible too with some assistance
from the dbus experts.

Ralf