Dlaczego firma Microsoft implementowała gniazda inaczej?

Question

Obecnie jestem w trakcie projektu z użyciem gniazd, a ja po prostu używam pliku sys/socket.h Linuksa. Podaj port Microsoftowi i zdaj sobie sprawę, że Winsock jest inny. Chyba mam dwa pytania.

Po pierwsze, jakie są główne różnice między tymi dwiema implementacjami? Czy istnieje prosty sposób na "przetłumaczenie" ich? Link do przewodnika byłby bardzo doceniany, ponieważ prawdopodobnie dostaniecie lepszej jakości linki niż Google.

Po drugie, dlaczego Microsoft to zrobił? Jaka była ich motywacja? Dlaczego po prostu nie zachowali tej samej implementacji jak wszyscy inni?

Answer 1

Przebacz mi, jeśli przeoczyłem kwestię, ale czy patrzysz na rodzinę z numerem WSARecv i że całe API gniazd w systemie Windows różni się od API Berkeley Sockets?

Interfejs API Berkeley istnieje w systemie Windows (patrz recv i rodzina) i jest w dużej mierze zgodny z każdą inną implementacją Berkeley Sockets.

Zobacz artykuł MSDN o numerze "Porting Socket Applications to Winsock", aby uzyskać informacje o przenoszeniu kodu gniazd do systemu Windows.

Answer 2

Spróbuj użyć ACE - jest to świetna biblioteka komunikacji między platformami.

Answer 3

Milen powiedział to w komentarzu, ale biblioteka Apache Portable Runtime obejmuje wiele problemów związanych z przenośnością dla aplikacji sieciowych.

Answer 4

Sekcja zawiera Winsock Programmer's FAQ, BSD Sockets Compatibility. (Ujawnienie: Jestem opiekunem FAQ Użytkownika).

naprawdę nie pokrycie whys i wherefores w tym artykule tak:

• winsock.h vs sys/socket.h ARPA /inet.h, netinet/in.h, itp.: To faktycznie znajduje ulepszenie. To jeden ciasny zestaw funkcji, więc dlaczego nie miałbyś wszystkich definicji w jednym nagłówku?

• close() vs. closesocket(): Powrót w oknach 3 dni po Winsock została wynaleziona, Windows C++ kompilatory wszystkie miały jakieś POSIX API owijki aby dostarczyć podstawowy poziom przenoszenia, w tym blisko() . Zostały one po prostu wywołane w implementacji stdio kompilatora, ponieważ DOS i Win16 nie miały zunifikowanego mechanizmu I/O, takiego jak Unices. Nie możesz po prostu wywołać metody close() na deskryptorze w Win16 i sprawić, by działał niezależnie od tego, czy jest to plik, gniazdo, potok, czy cokolwiek. Win32 istniał w tym samym czasie, w którym Winsock był wymyślany jako część NT 3.5, i to naprawia, ale uczynienie Winsock dostępnym tylko na pochodnych NT sprawiłoby, że MS byłby nieistotny w Internecie aż do Windows XP. MS może być powolne, ale nie powolne. Podsumowując, nic w gniazdach BSD, które używają mechanizmów POSIX, które kolidowały z istniejącymi API dostarczonymi przez kompilatory C++, które kierowały to po prostu nie mogły być w Winsock. Musieli nadać tej samej funkcjonalności nowe imię.

• WSA *(): To tylko dodaje funkcjonalności, zapewniając funkcjonalność gniazd BSD nie. Wiele z nich jest naprawdę miłych i byłoby miło zobaczyć podobne mechanizmy we wszystkich Unice, ale to nie wydarzy się w najbliższym czasie. Istnieją konkurencyjne mechanizmy, takie jak aio *(), ale nie jest to dostępne we wszystkich urządzeniach Unice, o wiele mniej przenośnych dla systemu Windows.Możesz go po prostu zignorować i trzymać się interfejsów API gniazd podstawowych, ale nie zawsze jest to najlepszy wybór podczas przenoszenia do systemu Windows.

• errno vs. WSAGetLastError(): errno jest częścią standardowego C, ale wartości błędów zależą od implementacji C. Należy pamiętać, że Winsock na początku nie był rzeczą specyficzną dla Microsoft. Systemy DOS i Windows nie zaczęły korzystać ze standardowych interfejsów sieciowych. Zostało to zapewnione przez strony trzecie, które zebrały się razem i wymyśliły Winsock z udziałem Microsoft. Początkowe stosy Winsock były wszystkie strony trzecie. Nie mogli napisać specyfikacji, aby nadpisać wartość errno C RTL, z kilku powodów. Te wartości błędów należały do ​​dostawcy winsock.dll, zupełnie innego świata niż C RTL.

• WSAStartup(), WSACleanup(): Znowu jest to spowodowane faktem, że winsock.dll był początkowo przez stronę trzecią pod warunkiem, rzecz, która sprzężona z jakiegoś bazowego stosu sieciowego, który nie jest częścią systemu operacyjnego . Istnieje również aspekt Win16: Win16 nie widział, że program po prostu umarł i automatycznie wyczyścił przydzielone mu zasoby. Musiałeś jawnie wydać wszystko, zanim skończył się program, albo wyciekły.

• Brak readv(), itp.: To nie miało sensu w świecie osób trzecich/Win16, w którym urodził się Winsock.