Which Winsock and accept()

Started by
3 comments, last by BlitzKrieg 21 years, 10 months ago
I''m creating a program that will be portable between both windows, and linux, i was wondering wether i should use winsock 1.1 or winsock 2. My main considerations are: If i used winsock 2 will it use more memory than if i use winsock 1.1? Does winsock 2 improve on the BSD compatible implementation in winsock 1.1 at all? Are there any other advantages/disadvantages to using winsock 2 over winsock 1.1 as far as BSD sockets compatibility goes etc.? Also, i am pretty sure the answer to this is no, but i want to make sure. Does accept() bind the new socket to a new port? or is it bound to the same port as the listening socket? And if it does bind a new port, is there any way to control which port it binds to? Thanks CYer, Blitz
Advertisement
I wrote a small cross platform code wrapper (self plug ) that includes sockets as one of the things it wraps. I technically used Winsock 2 as the Windows sockets front end (i.e. I include winsock2.h), but I avoided using any function that had a ''WSA'' on the front, so I could probably have pulled it off with Winsock 1.x. I''m don''t really know where the two differ though.

The manpage for accept says that it creates a socket ''with mostly the same properties as'' the socket you pass as parameter 1, if that helps any .

As long as you call as few of the WSA* functions as possible (like WSAStartup is required, so you can''t really avoid it) then you shouldn''t have many problems porting to a pure BSD implementation.

The socket returned by accept is ''bound'' to the same port as the listen socket. But that''s OK because you can have as many sockets bound to the listen port in this way as you like (well, ignoring any platform limitations, but these are in the order of a few thousand) and all data will be send to the right socket.

codeka.com - Just click it.
I thought accept() did bind the new socket to a totally new port. If you do a ntohs(newConnectionAddr.sin_port) it returns a port that has nothing to do with the listening port. And why would accept store a port in this structure if it doesn''t bind the new socket to that port as well?
Please correct me if I''m wrong.
It should be obvious that the address returned is the addressort at the _other end_ of the connection. So the established connection would go from say 1.2.3.4:1467 to 5.6.7.8:80. Assigning a new port would be unnecessary and very difficult: you''d have to reliably transmit the new port number to the client, which poses a lot of trouble. Changing the port on accept() would just be completely illogical.

cu,
Prefect

Return to the Shadows
Widelands - laid back, free software strategy

This topic is closed to new replies.

Advertisement