Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Należy zawsze uwzględniać wszelkie różnice między kolejnością bajtów używaną do przechowywania liczb całkowitych przez architekturę hosta i kolejności bajtów używanych na przewodach przez poszczególne protokoły transportu. Każde odwołanie do adresu lub numeru portu przekazywanego do lub z funkcji Windows Sockets musi znajdować się w kolejności sieciowej (big-endian) dla używanego protokołu. W przypadku IP, obejmuje to adres IP i parametry portu struktury sockaddr (ale nie parametr sin_family).
Wiele systemów UNIX działa na procesorach, które reprezentują liczby całkowite w sieciowej kolejności bajtów (big-endian). Dlatego konieczność konwertowania liczb całkowitych z kolejności bajtów hosta na kolejność bajtów sieciowych można zignorować bez powodowania problemów, nawet jeśli nie jest to zalecane do przenoszenia.
Natomiast kolejność bajtów używana do reprezentowania liczb całkowitych przez większość procesorów Intel® jest mała. Dlatego staje się obowiązkowe, aby liczby całkowite były konwertowane z kolejności bajtów hosta na kolejność bajtów sieciowych przed użyciem w funkcjach i strukturach gniazd winsock.
Rozważmy aplikację, która zwykle kontaktuje się z serwerem na porcie TCP odpowiadającym usłudze czasowej, ale zapewnia użytkownikowi mechanizm określania alternatywnego portu. Numer portu zwrócony przez getservbyname jest już w kolejności sieciowej, co jest formatem wymaganym do konstruowania adresu, dzięki czemu nie jest wymagane tłumaczenie. Jeśli jednak użytkownik zdecyduje się użyć innego portu wprowadzonego jako liczba całkowita, aplikacja musi przekonwertować ją z hosta na kolejność sieci TCP/IP (przy użyciu htons lub funkcji WSAHtons) przed użyciem go do utworzenia adresu. Z drugiej strony, jeśli aplikacja miała wyświetlić numer portu w adresie (zwrócony przez getpeername na przykład), numer portu musi zostać przekonwertowany z kolejności sieciowej na kolejność hosta (przy użyciu funkcji ntohs lub WSANtohs) zanim będzie można go wyświetlić.
Ponieważ kolejności bajtów Intel i Internet są różne, konwersje opisane powyżej są nieuniknione. Autorzy aplikacji są ostrzegani, że powinni używać standardowych funkcji konwersji udostępnianych w ramach usługi Winsock, a nie pisania własnego kodu konwersji, ponieważ przyszłe implementacje protokołu Winsock mogą być uruchamiane w systemach, dla których kolejność hostów jest identyczna z kolejnością bajtów sieciowych. Prawdopodobnie będą przenośne tylko aplikacje korzystające ze standardowych funkcji konwersji między kolejnością bajtów hosta i sieci.
Tematy pokrewne