Listening on Multiple Interfaces

 < Day Day Up > 



A common problem with the use of the bind call is what the address represents in a server socket scenario. Consider the following example:

int servsock, ret; struct sockaddr_in saddr; servsock = socket( AF_INET, SOCK_STREAM, 0 ); memset( &saddr, 0, sizeof(saddr) ); saddr.sin_family = AF_INET; saddr.sin_port = htons( 80 ); saddr.sin_addr.s_addr = inet_addr( "192.168.1.1" ); ret = bind( servsock, (struct sockaddr_in *)&saddr,             sizeof( saddr ) );

The developer has identified that the available Ethernet interface is configured with the IP address “192.168.1.1”. When the developer directs a client on the external network to the server using this snippet over the interface identified by “192.168.1.1”, all is well. However, what happens now if the address of the interface changes, or another interface is added? This lacks both portability and scalability. If the interface changes, all is lost as the bind will very likely fail. Additionally, external client sockets may not be able to access the server, even if the primary interface remained the same address (“192.168.1.1”). This is because the bind operation ties the server to the specific interface. Therefore, client connections may only connect through the interface having been configured with the address “192.168.1.1”. If the developer desires that all available interfaces be capable of routing client connections, the inet_addr line may be changed as follows:

saddr.sin_addr.s_addr = htonl( INADDR_ANY );

The INADDR_ANY symbolic (also known as the wildcard address) permits incoming connections from all available interfaces.



 < Day Day Up > 



BSD Sockets Programming from a Multi-Language Perspective
Network Programming for Microsoft Windows , Second Edition (Microsoft Programming Series)
ISBN: 1584502681
EAN: 2147483647
Year: 2003
Pages: 225
Authors: Jim Ohlund

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net