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

Я использовал его в режиме реального времени программирование. Мы обычно не делаем , хотят выполнить любое динамическое выделение (или освобождение) после того, как система запускает, потому что нет никакой гарантии, сколько времени это собирается взять.

то, Что я могу сделать, предварительно выделяют большой блок памяти (достаточно большой для содержания любой суммы того, чего это класс может потребовать). Затем как только я выясняю во времени выполнения, как создать вещи, новое размещение может использоваться для построения права объектов, где я хочу их. Одна ситуация я знаю, что использовал ее в, должна была помочь создать неоднородное кольцевой буфер .

Это, конечно, не для слабонервных, но вот почему они делают синтаксис для него довольно непростым.

8
задан Andrew Szeto 8 August 2009 в 12:29
поделиться

4 ответа

Простите, если я пропустил главное, но вы смотрите на WSARecv и семью,

14
ответ дан 3 November 2019 в 13:17
поделиться

The Winsock Programmer's FAQ has a section on this, BSD Sockets Compatibility. (Disclosure: I'm the FAQ's maintainer.)

I didn't really cover the whys and wherefores in that article, so:

  • winsock.h vs sys/socket.h, arpa/inet.h, netinet/in.h, etc.: This I actually find an improvement. It's all one tight set of functionality, so why not have all the definitions for it in a single header?

  • close() vs. closesocket(): Back in the Windows 3 days when Winsock was invented, Windows C++ compilers all had some kind of POSIX API wrapper to provide some basic level of portability, including close(). These just called down into the compiler's stdio implementation, since DOS and Win16 didn't have a unified I/O mechanism like Unices do. You can't just call close() on a descriptor in Win16 and have it work independent of whether it's a file, socket, pipe, whatever. Win32 existed at the same time as Winsock was being invented as part of NT 3.5, and it fixes this, but making Winsock available only on NT derivatives would have made MS irrelevant on the Internet until Windows XP. MS can be slow to the game, but not that slow. Bottom line, anything in BSD sockets that uses POSIX mechanisms that conflicted with existing APIs provided by the C++ compilers that targeted it just couldn't be in Winsock. They had to give the same functionality a new name.

  • WSA*(): This is just added functionality, providing functionality that BSD sockets doesn't. A lot of it is really nice, and it'd be nice to see similar mechanisms across all Unices, but that's not going to happen any time soon. There are competing mechanisms, like aio*(), but that isn't available across all Unices, much less portable to Windows. You can just ignore it and stick to the base sockets APIs, though this isn't always the best choice when porting to Windows.

  • errno vs. WSAGetLastError(): errno is part of Standard C, but the error values are up to the C implementation. Keep in mind that Winsock in the beginning was not a Microsoft-specific thing. DOS and Windows didn't start off having standard network APIs. This was provided by third parties, who all got together and invented Winsock, with Microsoft involved. The initial Winsock stacks were all third-party. They couldn't write the spec to be overwriting the C RTL's errno value, for several reasons. These error values belonged to the vendor-provided winsock.dll, a whole different world from the C RTL.

  • WSAStartup(), WSACleanup(): Again this is due to the fact that winsock.dll was initially a third-party provided thing, which interfaced with some underlying network stack that isn't part of the OS. Also, there's the Win16 aspect of things: Win16 couldn't see that a program just died and clean up its allocated resources automatically. You had to explicitly release everything before the program exited, or they'd be leaked.

  • Lack of readv(), etc.: This didn't make sense in the third-party/Win16 world where Winsock was born.

18
ответ дан 3 November 2019 в 13:17
поделиться

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

0
ответ дан 3 November 2019 в 13:17
поделиться

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

0
ответ дан 3 November 2019 в 13:17
поделиться
Другие вопросы по тегам:

Похожие вопросы: