easySockets TcpClient Wrapper Class

I wrote this class to inherit TcpClient and add some pre-written code for sending and receiving, synchronously and asynchronously, as well as connecting. Haven't gotten any disconnect code added in, but pretty much there's no real extrapolation to that function, so it's as simple as calling the base close command. I wrote this because I'm used to objects having properties, like Port and Address, that should be stored data for connecting, so that the info can be referenced later. Also because I looked at Asynchronous coding and thought to myself "well I could wrap up the code each time to do different things, or just have it throw an event for the ease of use." I preferred the event.

I tried to make sure it was well-documented and clean.

Please, I'd like some feedback on this: Is there anything that glaringly JUST WON'T WORK? Is there anything that SHOULD be in this? Is there anything that SHOULD NOT be in this? Any questions, comments, please, I'd love to know how it feels and looks.

Thanks to jmcilhinney, formlesstree4, and Atheist for their awesome assistance in helping me make this code.

Not sure how I managed to help, but glad to have. It doesn't look to bad, I'll have to find a way to test it to see how stable it is since I prefer Binary Serialization over sending Bytes.

Glad to see more contributions that involve the TcpClient as it can be tricky sometimes.

Do you have any information to share regarding Binary Serialization, what it is how it works how it's better than bytes

All I can tell you is to look at my TCP Client & Server classes, which show how to serialize and deserialize objects from the stream. It took a lot of guessing on my end to get it working (and quite a few google searches too).

Well, sir, what I did was I visited your lauded classes post that you updated yesterday, and for kicks downloaded the TCPClient.vb. I found some amazingly different ways of handling properties within a class ... in that instead of having private variables and the properties that interface with them, for a highly simplified class the properties are directly valued/devalued. That's interesting. Also how to create things "with" values, that's going to be interesting as an implementation -- much shorter code length and fewer commands in my own code.

Then I discovered the SendData command, and saw how it seemed to work. Passing an object to a stream, how odd. Then I spent some time in Object Browser, toying around and looking at Binary Formatter.

Then I realized just what you mean by this. Instead of having to format the data within the program to a string or series of bytes, that are almost completely abstract and hard to remember in coding terms, you merely throw an entire object, instance of a class, straight through the socket as a giant binary chunk, relying on both sides to be expecting that object.

It was at that point I had to consider obtaining new pants, as I was probably on the way to soiling myself with my shock. I never imagined it could be THIS easy.

Sir, you have destroyed my entire codeview, and for that I am grateful. I have much to learn, and already it looks like fun.

I'm glad that it looks fun to you. I can assure you that once I got it working properly I had a great deal of fun trying to push the system to its limits (2 million digits of Pi anyone?). I just serialized structures since it was much simpler than trying to manipulate bytes or strings or whatever else I could transmit. It just seemed like a great deal of crap for a little result.

It actually works pretty fast and I'm impressed with the results I get with it.

As you did see, SendData() was used to send raw data and I had specific wrappers that went around it, like SendMessage() for example. It filled in the necessary data along with the message and sender since all the other data is kept inside the Client object. I suppose it was a matter of time before it all worked anyway.

But on a side note: Hope your pants are OK, if not, a good thorough washing should fix it up. :)

I find myself wondering how the binary serialization of a class translates to text.

Premise: I'm writing a POP client. I want to use binary serialization to have "message" objects and such, which makes sorting information easier.

Problems: POP is a definitively text-based protocol. A request command is issued, a text-based reply returned.

Could that be translated or predicted to translate to a class object, and could said object translate back to those request commands...

It seems like binary serialization is only really appropriate when building one's own client and server for a specific or customized protocol, rather than building one's own client to interface with a common protocol.

Would you agree?

Yes. Binary Serialization for this type of thing is really useful for making a customized protocol of sorts. If you try to create a wrapper for another type of protocol (like POP), you'll have to go with the standards that are set by the POP servers. You can create structures that hold the data for end users of your wrapper to have easy access to, but that's it.