Sockets: Server Handling Networking in multiple services

fbregist's Avatar

fbregist

05 Jul, 2013 11:13 AM

OOOOk hi guys i'm here again :)
I feel so alone, there are no other programmers in my company and no one understand what means write a f***ing software...anyway it's another story.

Ok i'm writing a classic clients - server application and relatively to the server i'm going to structure the "network" services in a sort of "stack" the pipeline is:
- Listener service wait for a connection
     -When a client connect it takes the socket and wrap it in a TCPConnection Object that handles automatically (heartbeat, message framing etc)
      - Dispatch an event with the object
- Command react to the event and pass the object to a ConnectionsHandler Service
    - ConnectionsHandler register the listeners for the object and dispatch the connections event to the application, exposes methods to broadcast to al clients or send to a single.

Said this, first question: How would you handle the connection objects ? Storing them in the ConnectionsHandler service or in a model and let the service inject it?

Going on:
- I've another service that would handle the user authentication, so the step in my mind would be:
     - AuthService inject ConnectionsHandler
     - Listen for Messages from ConnectionsHandler
     - Login message -> wrap connection object in a userObject

Second question: where i store the authenticated clients (userObject)?? Model? service?

Third and last question: i think that you have understood what i mean...on top of the AuthService there will be an AppService tha will inject AuthService and listen only for the authenticated users messages, that's why i've said "stack" because each service inject another service.
Do you think that's a good architecture? this is the first time that i feel i'm doing a good job at architecturing my software :)

Thanks to the people that have read until here.

  1. Support Staff 1 Posted by Shaun Smith on 07 Jul, 2013 05:42 PM

    Shaun Smith's Avatar

    Hi. The "stack" approach sounds good. It sounds very similar to what I do - wrap a low level REST service instance with higher level application specific services.

    first question: How would you handle the connection objects ? Storing them in the ConnectionsHandler service or in a model and let the service inject it?

    Keep them in a model, and inject that model into your service.

    Second question: where i store the authenticated clients (userObject)?? Model? service?

    Perhaps in AuthenticatedClientsModel?

    Do you think that's a good architecture?

    It could be a good architecture, but no one can say without using it for a while. Try it out, see how it feels. If there are any bits that feel "fragile", "repetitive" or otherwise "painful" then change those bits.

  2. 2 Posted by fbregist on 08 Jul, 2013 09:34 AM

    fbregist's Avatar

    Thank you Shaun, i'm having always the same problem across several project and until now i've not found a solution:

    To indicate the messages types, i'm using a byte variable, i don't know how to convert that byte to the corresponding object and dispatch the corresponding event in a correct and fast way.
    I know there is the old switch statement but i feel like that it's not the correct way to handle this, maybe i'm wrong and all the online games and network applications use the switch but i don't think so.
    I've search all the web for information about network message handling protocol but i've not found anything useful

  3. Support Staff 3 Posted by Shaun Smith on 21 Jul, 2013 03:18 PM

    Shaun Smith's Avatar

    By the way, there is a very simple refactor for the Switch anti-pattern where you introduce a "config" object.

    Instead of doing this (psuedo-code):

    switch(message)  
      case "hello":
        x = 100;
        break;
      case "world"
        x = 200;
        break;
    

    You can do this:

    private const config:Object = {  
      hello: 100,
      world: 200 };
    
    // .. and then later you simply use that config as a look up
    
    x = config[message];
    

    You can almost always do this in places where you have a switch. If you need to call methods you just create a config object that has function references instead of values:

    private const config:Object = {  
      hello: method1,
      world: method2 };
    
    // .. and then later you simply use that config as a look up, and call
    
    config[message]();
    

    What happens in terms of reading the code is that, when you name things well (don't actually call it "config"!), the code becomes easier to parse mentally. You often don't even need to look at the config object to see what the calling code is trying to do. With a switch you basically have to read through all the switch cases to see what the "intent" is.

    What happens in terms of performance is that you end up with replacing a long series of "checks" with a single lookup.

  4. Ondina D.F. closed this discussion on 17 Aug, 2013 10:52 AM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac