Почему Microsoft реализовала сокеты по-другому?

Question

Я в настоящее время нахожусь в середине проекта с сокетами, и я просто использую файл sys / socket.h в Linux. Подберите порт для Microsoft и осознайте, что Winsock отличается. Я думаю, у меня есть два вопроса.

Во-первых, каковы основные различия между двумя реализациями? Есть ли простой способ «перевести» их? Ссылка на руководство будет принята с благодарностью, потому что, ребята, вы, вероятно, можете получить мне более качественные ссылки, чем Google.

Во-вторых, почему Microsoft сделала это? Какова была их мотивация? Почему они просто не сохранили ту же реализацию, что и все остальные?

Answer 1

Часто задаваемые вопросы по Программисту Winsock содержит раздел, посвященный Совместимости с сокетами BSD . (Раскрытие: я сопровождающий FAQ.)

В этой статье я не особо рассказал о причинах и причинах, поэтому:

• winsock.h против sys / socket.h, arpa / inet.h, netinet / in.h и т. Д. : В этом я считаю улучшение. Это все узкий набор функций, так почему бы не иметь все определения для него в одном заголовке?

• close () и closesocket () : В те 3-хдневные времена, когда был изобретен Winsock, в компиляторах Windows C ++ была какая-то оболочка POSIX API для обеспечения базового уровня переносимости. , в том числе close (). Они просто вызвали реализацию stdio компилятора, поскольку DOS и Win16 не имели единого механизма ввода-вывода, как Unices. Вы не можете просто вызвать close () для дескриптора в Win16 и заставить его работать независимо от того, является ли он файлом, сокетом, каналом, чем угодно. Win32 существовал в то же самое время, когда Winsock был изобретен как часть NT 3.5, и это исправляет это, но если бы Winsock был доступен только для производных NT, это сделало бы MS бесполезной в Интернете до Windows XP. MS может быть медленной в игре, но не , которая медленная. В итоге, ничего в сокетах BSD, использующих механизмы POSIX, которые конфликтуют с существующими API, предоставляемыми компиляторами C ++, которые нацелены на него, просто не может быть в Winsock. Они должны были дать той же функциональности новое имя.

• WSA * () : Это просто добавленная функциональность, обеспечивающая функциональность, которой не обладают сокеты BSD. Многие из них действительно хороши, и было бы неплохо увидеть подобные механизмы во всех Unices, но это не произойдет в ближайшее время. Существуют конкурирующие механизмы, такие как aio * () , но они доступны не во всех Unix, тем более менее переносимы для Windows. Вы можете просто проигнорировать это и придерживаться API базовых сокетов, хотя это не всегда лучший выбор при портировании на Windows.

• errno против WSAGetLastError () : errno является частью стандарта C, но значения ошибок соответствуют реализации C. Имейте в виду, что Winsock в начале не был предметом, специфичным для Microsoft. DOS и Windows изначально не имели стандартных сетевых API. Это было предоставлено третьими лицами, которые все собрались и изобрели Winsock с участием Microsoft. Начальные стеки Winsock были сторонними. Они не могли написать спецификацию для перезаписи errno-значения C RTL по нескольким причинам. Эти значения ошибок принадлежали предоставленной поставщиком winsock.dll, совершенно другому миру, чем C RTL.

• WSAStartup (), WSACleanup () : Опять же, это связано с тем, что изначально winsock.dll был предоставлен сторонним поставщиком, который взаимодействовал с каким-то базовым сетевым стеком, который не т часть ОС. Кроме того, есть аспект Win16: Win16 не мог видеть, что программа просто умерла, и автоматически очищал свои выделенные ресурсы. Вы должны были явно освободить все до выхода из программы, иначе они будут пропущены.

• Отсутствие readv () и т. Д. : Это не имело смысла в стороннем мире / Win16, где родился Winsock.

Answer 2

Простите, если я упустил момент, но вы смотрите на WSARecv и его семью и думаете, что весь API сокетов в Windows отличается от API сокетов Беркли?

API Беркли существует в Windows (см. recv и семейство) и в значительной степени совместимо с любой другой реализацией сокетов Беркли.

См. Статью MSDN "Перенос приложений сокетов в Winsock" для получения информации о переносе кода сокетов в Windows.

Answer 3

Милен сказал это в комментарии, но библиотека Apache Portable Runtime покрывает многие проблемы переносимости сетевого приложения.

Answer 4

Попробуйте использовать ACE - это отличная межплатформенная коммуникационная библиотека.