2009-08-08 36 views
7

Tôi hiện đang ở giữa dự án liên quan đến ổ cắm và tôi chỉ sử dụng tệp sys/socket.h của Linux. Cue cổng cho Microsoft, và nhận ra rằng Winsock là khác nhau. Tôi đoán tôi có hai câu hỏi.Tại sao Microsoft thực hiện ổ cắm khác nhau?

Trước tiên, sự khác biệt chính giữa hai triển khai là gì? Có cách nào dễ dàng để "dịch" chúng? Một liên kết đến một hướng dẫn sẽ được đánh giá cao, bởi vì các bạn có thể có thể giúp tôi có được các liên kết chất lượng tốt hơn Google.

Thứ hai, tại sao Microsoft thực hiện việc này? Động cơ của họ là gì? Tại sao họ không chỉ giữ cùng một triển khai như mọi người khác?

+1

Một cách để "dịch" Un * x sang Windows - http://apr.apache.org/docs/apr/1.3/group__apr__network__io.html –

Trả lời

12

Hãy tha thứ cho tôi nếu tôi đã bỏ lỡ điểm, nhưng bạn đang xem WSARecv và gia đình, và nghĩ rằng toàn bộ API socket trên Windows khác với API socket của Berkeley?

API Berkeley không tồn tại trên Windows (xem recv và gia đình) và phần lớn tương thích với bất kỳ triển khai Sockets Berkeley nào khác.

Xem bài viết MSDN "Porting Socket Applications to Winsock" để biết thông tin về cách chuyển mã ổ cắm vào Windows.

+0

Ồ không, tôi không nghĩ rằng toàn bộ API là khác nhau. Nếu không, các máy tính Windows sẽ giao tiếp với các máy tính * nix như thế nào? Nhưng tôi đã tự hỏi tại sao cú pháp lại khác. –

+1

@Andrew: "tự hỏi tại sao cú pháp lại khác": điểm của tôi là cú pháp * không * khác nhau - cùng một API Ổ cắm Berkeley mà bạn đang sử dụng trên Linux cũng có sẵn trên Windows. Hay chúng ta đang nói chuyện với nhau? Bạn có ví dụ về cách cú pháp khác nhau không? – RichieHindle

0

Hãy thử sử dụng ACE - đó là thư viện liên lạc nền tảng tuyệt vời.

0

Milen đã nói trong một nhận xét, nhưng thư viện Apache Portable Runtime bao gồm nhiều vấn đề về tính di động cho ứng dụng được kết nối mạng.

16

Winsock Programmer's FAQ có một phần về điều này, BSD Sockets Compatibility. (Tiết lộ: Tôi là người của thành trì.)

Tôi không thực sự bao gồm nguyên nhân tại sao và do gì trong bài viết đó, vì vậy:

  • winsock.h vs sys/socket.h, arpa /inet.h, netinet/in.h, v.v.: Điều này tôi thực sự tìm thấy một cải tiến. Đó là tất cả một bộ chức năng chặt chẽ, vậy tại sao không có tất cả các định nghĩa cho nó trong một tiêu đề duy nhất?

  • close() vs closesocket(): Trở lại trong Windows 3 ngày khi Winsock được phát minh, Windows C++ biên dịch tất cả đã có một số loại POSIX API wrapper để cung cấp một mức độ cơ bản của tính di động, trong đó có gần() . Chúng chỉ được gọi là thực hiện stdio của trình biên dịch, vì DOS và Win16 không có một cơ chế I/O thống nhất như Unices làm. Bạn không thể chỉ gọi close() trên một bộ mô tả trong Win16 và có nó làm việc độc lập cho dù đó là một tập tin, ổ cắm, đường ống, bất cứ điều gì. Win32 tồn tại cùng lúc khi Winsock được phát minh như một phần của NT 3.5, và nó sửa lỗi này, nhưng làm cho Winsock chỉ có sẵn trên các dẫn xuất NT sẽ làm cho MS không liên quan trên Internet cho đến Windows XP. MS có thể chậm trong trò chơi, nhưng không phải là chậm mà làm chậm. Tóm lại, bất cứ thứ gì trong các ổ cắm BSD sử dụng các cơ chế POSIX xung đột với các API hiện có được cung cấp bởi các trình biên dịch C++ đã nhắm mục tiêu nó không thể có trong Winsock. Họ đã cung cấp cho cùng một chức năng một tên mới.

  • WSA *(): Đây chỉ là chức năng bổ sung, cung cấp chức năng mà ổ cắm BSD không. Rất nhiều điều thực sự tốt đẹp, và thật tuyệt khi thấy các cơ chế tương tự trên tất cả các Unices, nhưng điều đó sẽ không xảy ra bất cứ lúc nào. Có các cơ chế cạnh tranh, chẳng hạn như aio *(), nhưng điều đó không có sẵn trên tất cả các Unices, ít di động hơn đối với Windows.Bạn chỉ có thể bỏ qua nó và gắn vào các API socket cơ sở, mặc dù đây không phải lúc nào cũng là lựa chọn tốt nhất khi chuyển sang Windows.

  • errno so với WSAGetLastError(): errno là một phần của tiêu chuẩn C, nhưng giá trị lỗi tùy thuộc vào việc triển khai C. Hãy nhớ rằng Winsock lúc đầu không phải là một điều cụ thể của Microsoft. DOS và Windows không bắt đầu có các API mạng chuẩn. Điều này được cung cấp bởi các bên thứ ba, tất cả những người đã cùng nhau và phát minh ra Winsock, với sự tham gia của Microsoft. Các ngăn xếp Winsock ban đầu là tất cả của bên thứ ba. Họ không thể viết spec để ghi đè giá trị errno của C RTL, vì nhiều lý do. Các giá trị lỗi này thuộc về winsock.dll do nhà cung cấp cung cấp, một thế giới hoàn toàn khác với C RTL.

  • WSAStartup(), WSACleanup(): Một lần nữa điều này là do thực tế là winsock.dll lúc đầu một bên thứ ba cung cấp điều, mà giao tiếp với một số ngăn xếp mạng cơ bản đó không phải là một phần của hệ điều hành . Ngoài ra, có những khía cạnh Win16 của sự vật: Win16 không thể thấy rằng một chương trình chỉ chết và làm sạch các nguồn tài nguyên được phân bổ tự động. Bạn phải tiết lộ rõ ​​ràng mọi thứ trước khi chương trình đã thoát, hoặc họ sẽ bị rò rỉ.

  • Thiếu readv(), v.v.: Điều này không có ý nghĩa trong thế giới bên thứ ba/Win16 nơi Winsock được sinh ra.

Các vấn đề liên quan