Network Connection OO Design Pattern

[Arta]

I don't think that 'need more data' will happen for outgoing messages. When you've decided to send something, you don't really want that send to be delayed because something needs more data. I can't imagine why an object  in the outgoing chain would need more data anyway?

Your incoming chain looks good, but under that model you'll have to make sure that the objects in the chain are ordered according to the amount of data they need before they can process something. I'm not sure that it's necessary to have that eventuality for all your objects, either: isn't it really only the final BNCS stage that gets to say "this is an incomplete message"? Why do the other objects have length requirements?

Thread B would certainly have to wait until thread A had provided enough data before it could process it. Why are you using a separate thread for processing, though? I'd do it all on one thread, or perhaps use a pool of worker threads - I think the latter is overkill for a client application, though, unless it's going to be doing an extraordinary amount of work.

[Adron]

It may happen if you need to filter outgoing b.net packets and get only the header first....

[Arta]

Why would you only get the header first? I'd think that would be an indicator of bad design.

[MyndFyre]

Why would you only get the header first? I'd think that would be an indicator of bad design.

This is going to be a server application.  ;-)

Thread B was there so that my looping mechanism didn't hold up the rest of the application.  But it was only used when I implemented my connection object knowing in advance the type of protocol I was using.

Also -- Adron suggested that I might use some type of encryption plugin that required a set number of bytes before it could process the message.  That number could easily be defined in the resultant filtered data.

[Banana fanna fo fanna]

I meant you should look at the java streams API for design decisions.

[Adron]

Why would you only get the header first? I'd think that would be an indicator of bad design.

If this is an easy-to-use generic network connection, that people can use to make bots, I could see one person writing a filter to do something useful, and some newbie writing a bot that sends one byte at a time, and those being used at the same time.

[Arta]

Hmm, yes, which would be bad design

In a highly OO system, outgoing messages should be encapsulated by some object. It shouldn't ever be possible to send bits of messages - which, in a command chain, should be atomic - separately. The incoming chain is a different matter, obviously.

[Adron]

Hmm, yes, which would be bad design

In a highly OO system, outgoing messages should be encapsulated by some object. It shouldn't ever be possible to send bits of messages - which, in a command chain, should be atomic - separately. The incoming chain is a different matter, obviously.

That's true, but the way I understood this system, it was meant to generically encapsulate a tcp stream. In a tcp stream, the minimum message is a byte. And if some part of the chain wants to process more than one byte at a time, it needs to be given the opportunity.

[MyndFyre]

Realistically, I wanted to be able to expose both methods.  I wanted to make it so that derived classes would be able to get the byte streams, but classes utilizing the derived class would simply receive the "message" objects.  I've used a similar design before, except that in my old classes, the derived classes controlled their own sockets.  This time, I want the base (even abstract) class to control the socket and provide a nice interface to derived classes.  But I don't know that it's possible.