U++ framework: U++ MT-multithreading and servers

Home » U++ Library support » U++ MT-multithreading and servers » Socket::IsOpen BUG/FIX (?)

Show: Today's Messages :: Polls :: Message Navigator
E-mail to friend

Socket::IsOpen BUG/FIX (?) [message #24489]

Wed, 20 January 2010 07:57

kohait00
Messages: 939
Registered: July 2009
Location: Germany

Experienced Contributor

hi there

in socket.h:73
class Socket

bool IsOpen() const { return !!data; }

is maybe wrong, since the Data class provides an IsOpen(), to which it should map, right?

so maybe like this:

bool IsOpen() const { return (data)?(data->IsOpen():(false); }

bool IsOpen() const { return data && data->IsOpen(); }

or do i miss something??

Report message to a moderator

Re: Socket::IsOpen BUG/FIX (?) [message #24497 is a reply to message #24489]

Wed, 20 January 2010 21:23

rylek
Messages: 79
Registered: November 2005

Member

Hello!

Conceptually you are right. I think the main reason for this awkwardness is historical evolution of the socket interface. The socket wrapper (class Socket) in practice receives its Data object only when it's open (through the ClientSocket / ServerSocket functions) and Socket::Close clears the internal pointer after closing the socket, so that for practical purposes (until now) it sufficed to check validity of the pointer. However with support for SSL and other extensions it started to be easier to allow the Data object to remain closed for a certain (initial) period. This is mainly to allow internal creation and initialization of the socket implementor object within the ClientSocket / ServerSocket functions, i.e. within "internals" of the socket hackery. I'm not sure what would happen if someone tried to put an unopened Socket::Data object into a Socket class. I'll discuss this with Mirek in greater detail but in any case I'm sure the modification you suggest is completely harmless and might prove itself valuable when dealing with various exceptional socket circumstances.

Regards

Tomas

Report message to a moderator