Hi all. I can't get the winsock2 inet_ntop to build. Using Xp pro vc++ 2008. I've looked here and on google but the all say to link Ws2_32.lib and wsock32.lib done that. I've see tutorials that use it Any Idea???????

Try to link against ws2_32 instead wsock32.

well that had no effect.
By the way I would search more but
The only net I have is a iPhone. I'm sorry for that and it does not
Work to well on this page.

Most of developers rewrite such library functions with their own. So probabably should you.

Standard library functions can be not-available on other platforms. They are writted decades ago and use outdated ineffective slow algoritms. If you write your own function - it will be faster and will be available to you on all platforms.

For example about ntop you can have a look into the source code of nginx web server. There is an ntop implementation that works much faster then the system one. In our network API we have rewritten it with similar approach but based on our own research. Being optimized for superscalar CPUs (and using a few another techniques) our implementation works about 30% faster then the one you can find in nginx source code.

In addtition to that I can say - the windows implementation (if I remember right as I didn't use it for quite quite a while :-) is called "inet_ntoa". It allocates memory that needs to be freed. Windows (multi-threaded) memory allocator is so incredibly slow so you should definitely avoid from using it.

Quote:Original post by ankhd
I can't get the winsock2 inet_ntop to build.

Does that function even exist? MSDN says:

Quote:The ANSI version of this function is inet_ntop as defined in RFC 2553. For more information, see RFC 2553 available at the IETF website.

Try using InetNtop instead.

Quote:is called "inet_ntoa". It allocates memory that needs to be freed. Windows (multi-threaded) memory allocator is so incredibly slow so you should definitely avoid from using it.

Are you sure about that?

Quote:The string returned by inet_ntoa resides in memory that is allocated by Windows Sockets. The application should not make any assumptions about the way in which the memory is allocated. The string returned is guaranteed to be valid only until the next Windows Sockets function call is made within the same thread.

the documentation implies a static (perhaps TLS-based) buffer is used for the char *, requiring no de-allocation.

Library function uses temporary buffer to render each log base 10 integer. Then the result is copied into a final buffer (that in it's case a temporary one looking from point of view of app logic). For IP address there is a need for 4 of such operations. And then you will copy from that buffer into your one owned by the app.

The optimized approach for IP to string conversion uses a kind of optimized log base 10 determination to avoid using temporary buffering for each number. Plus you can write data directly into the application buffer avoiding copying from the InetNtop buffer.

I won't post our function source here as it's forbidden. But you can get an nginx source and get a bit slower one to compare the performance against the standard library implementation.

You will see for yourself that rendering number into a final buffer avoiding 5 memcpy()s is noticable faster :) And if you apply a few optimizations to use scalar possibilities of modern CPUs - you will get even bigger gain in performance.

Btw. accessing TLS storage is also an overhead. If it's not TLS-based - static means no thread safety.

Anyway each developer must decide what is best for him. I'm not insisting on any of approaches. Just giving overview on possibilities. Using own high-speed functions is good at applications like log file processing or at highly scalable servers. When conversion of IPs is not so frequent - usual functions may be quite enough.

Quote:Original post by hplus0603
In my opinion, the implementation needs to be no more complex than an sprintf() using masking of the proper inet address bytes (for IPV4; IPV6 is slightly more complex). I'd be highly surprised if the performance of inet_ntoa/inet_ntop would ever show up under pretty much any circumstance.

sprintf itself is slower as you have to parse at least 15 bytes of format one by one with a lot of branching :)

I'm using own sprintf implementation that is around 286% faster than standard. Additional 15% performance gain when printing numbers are archieved by using logarithms to avoid temporary buffering.

However even a faster own sprintf around 10 times slower than own inet_ntoa (ntop is similar except it takes struct as argument) due to a lot of branching needed to parse format string.

I do agree that there are not much of tasks where the performance of such algorithms is an issue :)

I mostly use own algorithms for the compatibility issues to stay independent of platform specific implementations. Optimization is something like extra bonus but the main reason for me is a compatibility and portability for cross-platform development.