change the subclass of a socket on the fly?

I have a server socket that can receive several different kinds of connections. Currently I’m passing the received socket off to another class that handles the data via a class interface so no matter what class is actually going to handle the request the socket can pump the data available and error events into it via the known interface methods.

This works but is becoming messy as the latest protocol I’d like to implement is not easily discerned before the data starts to flow.

What I’d like to do instead is to be able to discern what I’m talking to in the original socket as handed off by the server and then pass that stream reference off to a new socket class. As if I could use the .handle property of the socket to pass to the constructor of a new socket subclass that knew about the specific protocol. Or something similar. Is such a thing possible now? If not is there enough value in this sort of thing that I should bother making a feature request? Or is there some better way to do this other than using a class interface and passing a reference to it’s handling class to the socket? I looked at the details of the new framework sockets but it doesn’t seem to be possible there either. Or is the handle property read/write on that? It didn’t seem so.

Any suggestions welcome, thanks!

I’ve done something similar by making different Easy/TCPSocket subclasses, then returning those for the new connection. I don’t think you can instantiate a new socket from a previous socket. Normally the best practice is to code once. Have your socket subclass do what is expected based on a version number shared by the client, or something similar. I’ve also, in the past, had the client establish a new connection on a certain port number to interact with a different ServerSocket and get a separate subclass applied to the connection.

You could create a series of classes connected either by interface or a super which gets instantiated at runtime and connected to the socket via a property on the socket itself. Then just check if the property is Nil and if not, call into the class. If it is Nil, then your socket is still in its startup phase.

Yes, this is basically what I’m doing now. It has worked fine for a long time but is not as nice a design as I have a lot of checking of flags in the initial socket connection to know which interface class to go looking for and pass off the data to. It’s just messy and is getting more so as time goes by so I’m looking for better options. Just for my own sustainability internally.

I’m confused why that would be. Seems to me that if you used the same interface for them all, you’d only have to check once up front.

Basically make them all black boxes.