2010-01-15 1 views
2

Каждый упоминал это как Программирование сокетов или Сетевое программирование в C, и мы начали использовать его, используя sys/socket.h & netinet/in.h. Мы думали, что это на 100% верно. Но вопрос, поднятый в моей голове, когда я увидел эту книгуКакие еще API-интерфейсы сокетов доступны? Каковы различия между каждым из этих Socket API?

межсетевых с TCP/IP Том III: Клиент-Сервер программирования и приложений, который был доступен в 4 различных вариантах

  1. Linux/POSIX сокеты
  2. AT & T TLI (Transport Layer Interface) Головки
  3. BSD (Беркли) розетки
  4. Window розетки

Я в замешательстве. Это ясно показывает, что для Socket API нет стандарта.

также я удивлен увидеть sys/socket.h & netinet/in.h, которые являются частью библиотеки POSIX C в http://en.wikipedia.org/wiki/Berkeley_sockets. Теперь я больше смущен.

  1. Почему нет стандарта для этого?
  2. Какие еще API-интерфейсы сокетов доступны?
  3. В чем разница между каждым из этих Socket API?
  4. Когда люди говорят, что просто «Сетевое программирование в C»/«Программирование сокетов», что именно они имеют в виду?
  5. Ссылки для получения дополнительной информации?

ответ

5

Почему нет стандарта для этого?

Стандарт де-факто - это разъемы BSD, на которых основаны API-интерфейсы Linux, POSIX и Windows.

Какие еще API-интерфейсы сокетов доступны?

Ничего, что все еще широко используется. До того, как сокеты BSD и их производные заняли мир, их было много. Большинство из тех, которые остаются, вероятно, во встроенном мире, и даже те, которые уходят, поскольку основные ОС продолжают поглощать все больше и больше встроенного рынка.

Это сражение в значительной степени сражалось и заканчивалось к середине 90-х годов. Победители BSD выиграли.

В чем разница между каждым из этих Socket API?

Существуют незначительные различия между вариантами BSD, Linux и POSIX, не более серьезными, чем любые другие различия между операционными системами Unixy.

Причина, по которой у них есть версия для Linux/POSIX, вероятно, имеет больше общего с маркетингом, чем что-либо техническое. Он отвечает на вопрос, который издатель, вероятно, видел много: «Зачем мне нужна книга BSD, я запускаю Linux, а не BSD!» Или, чаще всего, в эти дни: «Что такое BSD?»

С точки зрения 10 000 футов Winsock сильно отличается от сокетов BSD, но поскольку это довольно строгий суперсет из разъемов BSD, вы все равно можете переместить свои знания. Большинство различий - это чистые расширения для сокетов BSD, в основном это касается различий в архитектуре ядра Windows и способах создания Windows-программ. Например, первым действительно большим расширением были асинхронные сокеты, что упрощает использование сокетов в однопоточной программе Windows GUI, чем использование чистых сокетов BSD. Более поздние расширения поддерживают специальные функции, доступные в ядрах NT, которые не имеют простого аналога в системах Unixy, таких как объекты событий и перекрывающиеся ввода-вывода.

Для того, что стоит, в некоторых системах Unixy есть расширения для обычных старых BSD-сокетов, например, aio_*() в Solaris и других системах.

Если ваша программа должна быть совместима со многими системами, вы либо игнорируете эти различия, либо проецируете на общую базу, используемую всеми этими системами, или создаете какой-то слой перевода, который позволяет прозрачно использовать функции платформы. Apache делает это, например, используя самые быстрые сетевые функции на каждой платформе, в то время как основной код веб-сервера не заботится точно о том, как делается сеть. Многие другие программы выбирают переносной путь, так как они не критичны по производительности, поэтому более важно сохранить время программиста.

Когда люди говорят, что просто «Программирование сети в C»/«Программирование сокетов», что именно они имеют в виду?

BSD гнезда или какой-либо вариант.

Ссылки для получения дополнительной информации?

The Winsock Programmer's FAQ. В частности, вы можете посмотреть его раздел resources и статью BSD Sockets Compatibility.

(Отказ от ответственности:. Я сопровождающий часто задаваемых вопросов)

2

API-интерфейсы Linux, BSD и Windows (по крайней мере, я не знаю о AT T TLI API) очень похожи друг на друга. Например, API Windows является/был первоначально основан на BSD API.

+0

Да, 4 разных имени фактически не означают 4 совершенно разных реализации. По крайней мере, с 3, о которых вы говорите, это почти то же самое с несколькими специфичными для платформы причудами. – Kylotan

2

Почему нет стандарта для этого?

Есть. Вы назвали несколько. Любой может опубликовать «стандарт», там не обязательно быть одним, и нет какого-то контролирующего органа, обладающего полномочиями «One True Way». Что касается сетей, то реальными стандартами являются сами сетевые протоколы. Каждый должен взаимодействовать с ними, или ничего не работает вместе. Как любая данная платформа реализует API для достижения этой цели, может различаться.

В чем разница между каждым из этих Socket API?

Linux/POSIX/BSD все схожие. Windows немного отличается, но поскольку она по-прежнему должна поддерживать базовые протоколы, функциональность заканчивается почти одинаковой. Честно говоря, я не уверен, кто использует AT & T TLI, если они когда-либо делали.

Какие еще API-интерфейсы сокетов доступны?

Существует, вероятно, много, но речь идет о том, кто их больше использует. IBM имел обыкновение иметь кучу, а также большинство других крупных производителей в тот же день. Но я думаю, что они по большей части были удалены в корзину для сбора пыли, поскольку большинство из них использует TCP.

Когда люди говорят, что просто «Программирование сети в C»/«Программирование сокетов», что именно они имеют в виду?

Ничего точно. Технически язык C ничего не знает о сетевом программировании. Однако многие поставщики (например, Unix, Linux, Windows и т. Д.) Предоставляют библиотеки C для выполнения сетевых операций, следовательно, многие API, которые вы указали выше.

1

ИТ интерфейса фактически выровнены OSI. Novell также отправляли его за один раз. Это устарело. API-интерфейсы Linux и Winsock основаны на BSD API, тесно в случае с Linux, что менее важно для Winsock. В обоих случаях также существуют небольшие различия в реализации.