[JAVA] Chatserver Model

[Kwistnix]

Omdat ik met sockets en threads in Java wil leren werken ben ik van plan om zelf een chatserver te ontwikkelen (en ook een client). Ik ben zelf al bezig geweest met een concept classdiagram. Aangezien dit mijn eerste project is dat met sockets en threads werkt (ik heb de theorie wel bestudeerd en kleine test applicatiess gemaakt) wil ik eerst zeker weten of er geen faliekante fouten in mijn model zitten

Ik heb er één groot classdiagram van gemaakt om het "overzichtelijk" te houden:
http://people.zeelandnet.nl/jelleklap/ChatServer.jpg


Alle commentaar is welkom

[Alarmnummer]

Ik zal even niet ingaan op je model, maar heb vragen over je middleware keuze. Ik zou persoonlijk absoluut niet gaan voor sockets maar voor een hogere laag zoals RMI. En dat zou ik zelfs nog niet willen gebruiken, want ik denk dat JMS (Java Messaging System) hiervoor de beste oplossing is.

[Alarmnummer]

Opmerkingen over je model:

-waarom heb jij een aparte chat protocol? Niet dat ik hier problemen mee heb, maar is deze verantwoordelijk voor de vertaalslag socket->java java->socket?

-waarom heeft jouw chatserver en jouw chatchannel een user list? Ik snap dat er users op jouw server kunnen staan, en users in de chatchannel, maar je hebt nu een stuk redundantie in je systeem. Via de chatchannel kan je ook bij de users komen, en vanaf de chatserver kan je bij de chatchannels komen. Ik zie dus niet in waarom je ook nog eens van de chatserver direct bij de userlist wilt komen

Ik zou verder een beetje oppassen met allerlei collectie structuren zelf te gaan implementeren/extenden. Ik gebruik zelf collectie structuren uit het Collectionsframework zoals de List,Map, Set etc en maak zelf niet vaak aparte subclasses ervan aan.

-jij hebt 1 chat channel op je chatserver?

-Wat doen die servercontroller/serverview daar?? Wat is het nut ervan??

-ik snap het stuk vanaf de chatsession niet.

Verder moet je enorm oppassen met threads dat je geen concurrency problemen gaat krijgen zoals race problemen en deadlocks. Ik zou persoonlijk werken met een berichten systeem. Als sockets thread merkt dat er een bericht binnenkort, dan plaatst hij dat bericht in een verwerkingsqueue. Berichten heb je er in allerlei soorten en maten, zoals GebruikersTekstMessage, BanUserMessage, ShutDownServerMessage,NewUserMessage. Deze berichten plaats je in een queue, waarachter 1 thread op ligt te maffen mbv een semafoor. Het voordeel van deze aanpak is dat je aan de voorkant van je systeem een hele lading bericht genererende threads hebt die berichtjes in de berichtenqueue plaatst. Maar achter deze queue is nog maar 1 thread actief, dus afgezien van de berichtenqueue hoef je hoeft geen rekening meer te houden met concurrency control.

Hoe ben je trouwens van plan gebruikers in te lichten wanneer er een nieuw bericht is binnengekomen? Dat kan ik namelijk niet uit je model afleiden.

[ Voor 36% gewijzigd door Alarmnummer op 24-04-2004 18:58 ]

[Kwistnix]

Alarmnummer schreef op 24 april 2004 @ 18:51:
Opmerkingen over je model:

-waarom heb jij een aparte chat protocol? Niet dat ik hier problemen mee heb, maar is deze verantwoordelijk voor de vertaalslag socket->java java->socket?

Ja

-waarom heeft jouw chatserver en jouw chatchannel een user list? Ik snap dat er users op jouw server kunnen staan, en users in de chatchannel, maar je hebt nu een stuk redundantie in je systeem. Via de chatchannel kan je ook bij de users komen, en vanaf de chatserver kan je bij de chatchannels komen. Ik zie dus niet in waarom je ook nog eens van de chatserver direct bij de userlist wilt komen

Het is niet dezelfde userlist. De userlist van de server is een lokale lijst op de server, daar staan bijv server admins, channel-ops etc. in. Misschien verkeerd geredeneerd en gemodelleerd, maar hoe zou jij dat dan doen?

-Ik zou verder een beetje oppassen met allerlei collectie structuren zelf te gaan implementeren/extenden. Ik gebruik zelf collectie structuren uit het Collectionsframework zoals de List, Map, Set etc en maak zelf niet vaak aparte subclasses ervan aan.

Dus ik moet i.p.v. de runnable interface te implementeren de class thread extenden?

-jij hebt 1 chat channel op je chatserver?

Dat zag ik dus ook net naar aanleiding van je eerdere opmerking, ik moet nog een channellist bijhouden

-Wat doen die servercontroller/serverview daar?? Wat is het nut ervan??

Dat is het lokale UI die gebruikt wordt om de server te configureren en die hoort eigenlijk niet thuis in dit diagram.

-ik snap het stuk vanaf de chatsession niet.

Een chatsession heeft een eigen socket en draait binnen een eigen thread op de server? De multipliciteit is in iedergeval verkeerd aangegeven in mijn diagram.

[ Voor 7% gewijzigd door Kwistnix op 24-04-2004 19:03 ]

[Kwistnix]

Alarmnummer schreef op 24 april 2004 @ 18:45:
Ik zal even niet ingaan op je model, maar heb vragen over je middleware keuze. Ik zou persoonlijk absoluut niet gaan voor sockets maar voor een hogere laag zoals RMI. En dat zou ik zelfs nog niet willen gebruiken, want ik denk dat JMS (Java Messaging System) hiervoor de beste oplossing is.

Het doel van dit project is o.a. om leren gaan met sockets en niet zuiver en alleen het maken van een chatserver.

[Alarmnummer]

Kan je je [quote] tekens in je vorige bericht ff goed zetten? Ik kan nou geen commentaar geven op jouw antwoorden.

[Alarmnummer]

-waarom heb jij een aparte chat protocol? Niet dat ik hier problemen mee heb, maar is deze verantwoordelijk voor de vertaalslag socket->java java->socket?

Ja

Waarom is dit protocol dan niet gekoppeld aan die chatsession?

-waarom heeft jouw chatserver en jouw chatchannel een user list? Ik snap dat er users op jouw server kunnen staan, en users in de chatchannel, maar je hebt nu een stuk redundantie in je systeem. Via de chatchannel kan je ook bij de users komen, en vanaf de chatserver kan je bij de chatchannels komen. Ik zie dus niet in waarom je ook nog eens van de chatserver direct bij de userlist wilt komen

Het is niet dezelfde userlist. De userlist van de server is een lokale lijst op de server, daar staan bijv server admins, channel-ops etc. in. Misschien verkeerd geredeneerd en gemodelleerd, maar hoe zou jij dat dan doen?

Channel-ops moeten bij de channel userlist staan. Verder zou ik als je toch verschillende soorten gebruikt hebt, ook subclasses gaan maken voor user. Admin, Normal,ChannelOp,Looker. Verder zou ik persoonlijk gewoon een List implementatie zoals Vector of ArrayList gebruiken om die gebruikers in te plaatsen:

code:

class Channel{
      private List<User> _userList = new ArrayList<User>();

      public void addUser(User user){
             //misschien checks + events rondsturen
             _userList.add(user);
      }

      public void removeUser(User user){
             //misschien checks + events rondsturen
            _userList.remove(user);
      }

      public List<User> getUserList(){
            return Collections.unmodifiableList(_userList);
            //niemand behalve deze Channel class mag die userlist aanpassen. 
            //Dus daarom geeft je een onveranderbare list terug.
      }
}

-Ik zou verder een beetje oppassen met allerlei collectie structuren zelf te gaan implementeren/extenden. Ik gebruik zelf collectie structuren uit het Collectionsframework zoals de List, Map, Set etc en maak zelf niet vaak aparte subclasses ervan aan.

Dus ik moet i.p.v. de runnable interface te implementeren de class thread extenden?

Dat heeft niets met te maken met het maken van eigen collectie structuren. Verder moet je altijd werken met Runnable.

-ik snap het stuk vanaf de chatsession niet.

Een chatsession heeft een eigen socket en draait binnen een eigen thread op de server? De multipliciteit is in iedergeval verkeerd aangegeven in mijn diagram.

Daar heb ik niet eens op gelet. Maar zoals ik hierboven al gezegd heb, zou ik dus enorm oppassen met thread. Kijk mijn oplossing nog even goed door met het versturen van berichten. Je bent dan van alle concurrency problematiek af.

[ Voor 3% gewijzigd door Alarmnummer op 24-04-2004 19:17 ]

[Kwistnix]

ChatProtocol moet inderdaad aan ChatSession hangen! - Aangepast


Wat betreft de users, ik maak voorlopig onderscheid tussen vier soorten:

• Unregistered Users - geen rechten
• Registered Users - rechten om eigen user info aanpassen.
• Server Admins - rechten om server settings te wijzigen, zij het lokaal of remote).
• Channel Operators - rechten om een bepaald kanaal te beheren.

De laatste drie categorieën moet dus persistent op de server opgeslagen worden.
De unregistered users moeten alleen op een tijdelijke lijst weergegeven worden wanneer de server online is. Ik maak dus onderscheid tussen twee verschillende UserLists. Kan ik dit niet op deze manier modelleren?


Wat bedoel je dan met "Ik zou verder een beetje oppassen met allerlei collectie structuren zelf te gaan implementeren/extenden." Ik implementeer vooralsnog alleen de runnable interface, verder extend of implenteer ik niets.


Zoals ik de ChatSession (+relaties) gemodelleerd heb kan het in principe dus wel? Ik ben me er zeer van bewust dat het niet de handigste of meest probleemloze oplossing is, maar zoals ik al zei: ik wil met threads leren werken (meerdere threads tegelijk runnen en met elkaar synchroniseren in dit geval).

[ Voor 6% gewijzigd door Kwistnix op 24-04-2004 19:47 ]

[Alarmnummer]

FallenAngel666 schreef op 24 april 2004 @ 19:41:
ChatProtocol moet inderdaad aan ChatSession hangen! - Aangepast

Wat betreft de users, ik maak voorlopig onderscheid tussen vier soorten:

• Unregistered Users - geen rechten
• Registered Users - rechten om eigen user info aanpassen.
• Server Admins - rechten om server settings te wijzigen, zij het lokaal of remote).
• Channel Operators - rechten om een bepaald kanaal te beheren.

De laatste drie categorieën moet dus persistent op de server opgeslagen worden.
De unregistered users moeten alleen op een tijdelijke lijst weergegeven worden wanneer de server online is. Ik maak dus onderscheid tussen twee verschillende UserLists. Kan ik dit niet op deze manier modelleren?

Ik zou sowieso even subclasses aanmaken of werken met roles.

code:

class Role{}

class AdminRole extends Role{}

class ChannelOpRole extends Role{}

class RegUserRole extends Role{}

En dan moet iedere User een lijst met roles terugsturen die hij allemaal kan vervullen. Je kunt bij het inloggen van een user kijken in de database welke roles hij allemaal kan vervullen en maak je een User object aan met een lijst van al deze roles.

Wat bedoel je dan met "Ik zou verder een beetje oppassen met allerlei collectie structuren zelf te gaan implementeren/extenden." Ik implementeer vooralsnog alleen de runnable interface, verder extend of implenteer ik niets.

Dat ik een beetje huiverig ben voor UserList AutoList OnderdeelList classes. Dus geen onzinnige eigen collectie structuren maken, maar gewoon gebruiken die in het Collectionframework zitten.

Zoals ik de ChatSession (+relaties) gemodelleerd heb kan het in principe dus wel?

Als de ChatSession

Ik ben me er zeer van bewust dat het niet de handigste of meest probleemloze oplossing is, maar zoals ik al zei: ik wil met threads leren werken (meerdere threads tegelijk met elkaar synchroniseren in dit geval).

Ik met mijn jaren ervaring zou het nog een hele lastige klus vinden om in dit al redelijk complexe systeem te kunnen garanderen dat dit ding thread safe is. Ik denk dat het voor een beginner dan echt veel te lastig is. Met mijn oplossin werk je ook met threads. Als je jouw Session object pakt, dan is er een thread actief die bezig is de socket naar de client uit te lezen. Als hij genoeg info heeft, bakt hij daar een Message van. En deze message plaatst hij dan in 1 of andere centrale messagequeue. Er kunnen dus heel veel ChatSession threads actief zijn (wat jij graag wilt) maar al deze ChatSessions kunnen praten met 1 object: de MessageQueue. Dit object moet je dus threadsafe maken omdat er dus zoveel threads mee lopen te kletsen. Aan de andere kant van deze queue is een werker (Thread) actief die zit te wachten totdat een Message binnenkomt (dit kan je voor elkaar krijgen met bv een semafoor). Komt er een binnen, dan haalt hij deze uit de queue en gaat beginnen het bericht te verwerken. Berichten zoals NewUserMessage,UserWilStoppen,UserStuurtBan (wel ff controleren of hij wel de juiste roles daarvoor heeft) die kan die werker dus allemaal tegenkomen en verwerken. Deze worker mag met alle andere objecten in je systeem praten zonder dat je nog bang hoeft te zijn voor concurrency problemen omdat er maar 1 thread in dat gedeelte actief is, namelijk hijzelf.

Ik denk dat dit de meest handige oplossing is om dit complexe thread probleem op een goeie manier op te lossen. Als jij niet oppast ga je race problemen krijgen (omdat je iets niet goed hebt afgeschermt). Maar als je te veel gaat afschermen, dan loop je weer het risico op deadlocks. Het allervervelendste aan threadproblematiek is dat het heel lang goed kan gaan en dan ineens... reageert je server niet meer. Jij kan dus met deze oplossing nog genoeg spelen met threads, maar je komt niet hopeloos vast te zitten in het bedenken van een goeie oplossing.


Hoe ben je verder van plan om gebruikers op de hoogte te stellen? Stel dat een channel wordt verwijdert, of een user gebanned, of een andere user typt een bericht?

[ Voor 7% gewijzigd door Alarmnummer op 24-04-2004 20:12 ]

[Kwistnix]

Alarmnummer schreef op 24 april 2004 @ 20:01:

Ik zou sowieso even subclasses aanmaken of werken met roles.

code:

class Role{}

class AdminRole extends Role{}

class ChannelOpRole extends Role{}

class RegUserRole extends Role{}

En dan moet iedere User een lijst met roles terugsturen die hij allemaal kan vervullen. Je kunt bij het inloggen van een user kijken in de database welke roles hij allemaal kan vervullen en maak je een User object aan met een lijst van al deze roles.


Subclasses maken was ik sowieso van plan, maar die heb ik in mijn diagram weggelaten (context niveau). Echter, dat werken met Roles vind ik een veel sterkere oplossing! Ik zal m'n usermodel daar op baseren. Bedankt voor de tip!

---------

Dat ik een beetje huiverig ben voor UserList AutoList OnderdeelList classes. Dus geen onzinnige eigen collectie structuren maken, maar gewoon gebruiken die in het Collectionframework zitten.


Op die manier. Voor de duidelijkheid ik heb die klasse zo genoemd om het diagram begrijpelijk te maken. Ik ben er nog niet uit welke datastructuur ik het beste kan gebruiken om users of channels bij te houden. In iedergeval was ik niet van plan om een eigen implementatie van een Red-Black Tree of iets dergelijks te maken

---------

Als de ChatSession


Als de chatsession wat?

---------

Ik met mijn jaren ervaring zou het nog een hele lastige klus vinden om in dit al redelijk complexe systeem te kunnen garanderen dat dit ding thread safe is. Ik denk dat het voor een beginner dan echt veel te lastig is. Met mijn oplossin werk je ook met threads. Als je jouw Session object pakt, dan is er een thread actief die bezig is de socket naar de client uit te lezen. Als hij genoeg info heeft, bakt hij daar een Message van. En deze message plaatst hij dan in 1 of andere centrale messagequeue. Er kunnen dus heel veel ChatSession threads actief zijn (wat jij graag wilt) maar al deze ChatSessions kunnen praten met 1 object: de MessageQueue. Dit object moet je dus threadsafe maken omdat er dus zoveel threads mee lopen te kletsen. Aan de andere kant van deze queue is een werker (Thread) actief die zit te wachten totdat een Message binnenkomt. Komt er een binnen, dan haalt hij deze uit de queue en gaat beginnen het bericht te verwerken. Berichten zoals NewUserMessage,UserWilStoppen,UserStuurtBan (wel ff controleren of hij wel de juiste roles daarvoor heeft) die kan die werker dus allemaal tegenkomen en verwerken. Deze worker mag met alle andere objecten in je systeem praten zonder dat je nog bang hoeft te zijn voor concurrency problemen omdat er maar 1 thread in dat gedeelte actief is, namelijk hijzelf.

Ik denk dat dit de meest handige oplossing is om dit complexe thread probleem op een goeie manier op te lossen. Als jij niet oppast ga je race problemen krijgen (omdat je iets niet goed hebt afgeschermt). Maar als je te veel gaat afschermen, dan loop je weer het risico op deadlocks. Het allervervelendste aan threadproblematiek is dat het heel lang goed kan gaan en dan ineens... reageert je server niet meer. Jij kan dus met deze oplossing nog genoeg spelen met threads, maar je komt niet hopeloos vast te zitten in het bedenken van een goeie oplossing.


Ok. Ik ben overtuigd
Dat betekend wel wat dat ik wat uitzoekwerk moet verrichten. Heb je misschien een handige bron die ik kan raadplegen? Theorie in combinatie met sample code zou ideaal zijn.

----------------

Bedankt voor het serieus meedenken trouwens

[Alarmnummer]

Op die manier. Voor de duidelijkheid ik heb die klasse zo genoemd om het diagram begrijpelijk te maken. Ik ben er nog niet uit welke datastructuur ik het beste kan gebruiken om users of channels bij te houden. In iedergeval was ik niet van plan om een eigen implementatie van een Red-Black Tree of iets dergelijks te maken

Ik zou die lijst uit je class diagram laten. Een ChatChannel kan meerdere Users bij zich hebben en dat is alles wat je hoeft te weten. Hoe dat intern wordt opgelost (bv met een arraylist) gaat niemand wat aan en moet niet in je uml diagram.

Ok. Ik ben overtuigd
Dat betekend wel wat dat ik wat uitzoekwerk moet verrichten. Heb je misschien een handige bron die ik kan raadplegen? Theorie in combinatie met sample code zou ideaal zijn.

Java:

abstract class Message{
    //stuurt de user terug die deze message heeft verzonden
    User getUser(){...} 

     //wordt aangeroepen door de messageworker
    abstract void execute();
}

class BanMessage extends Message{
    User getIrritatingUser(){...}
    
    void execute(){
        //haal de irritante user uit de chatchannel 
        //userlijsten en gooi hem in een blacklist ofzo
        //zodat ie nooit meer kan inloggen.
    }
}

class MessageQueue{
      
    private Queue<Message> _queue = new Queue<Message>();
 
    void post(Message message){
        _queue.push(message)
    }

    Message get(){
        return  _queue.get();
    }
}

class MessageWorker implements Runnable{
    
    void run(){     
        while(true){//je kan hier werken bv met een stop conditie.
            
            //zo lang er geen message in de message queue staat, blijf je slapen.
            Message message = messageQueue.get();
            //heej.. bericht is binnen... nu kan die verwerkt worden.
            
            message.execute();
        }
    }
}


class ChatSession{

    Socket _socket = ...;   
    User _user;
    
    class MessageCreatingWorker implements Runnable{
          while(true){
              String messageSoort = socket.leesDeSoort();
              if(messageSoort.equals("ban")){
                  String bannedUserStr = socket.leesDeUser();
                  User bannedUser = haalDeUserDieHierBijHoort(bannedUserStr);
                   BanMessage message = new BanMessage(_user,bannedUser)
                   _messageQueue.post(message);
              }else if....
                          
              else{
                ..onbekend commando.. wat nu?
              }
          }         
    }
}

Een voorbeeldje. Ik heb trouwens expres niet aan concurrency control gedaan, want dat mag je zelf gaan doen. Verder moet je ook even kijken naar het Command design pattern, en het Reactor design pattern. Dan zal je wel heel veel duidelijk worden.

Bedankt voor het serieus meedenken trouwens

np.. leer er zelf ook van.

[ Voor 30% gewijzigd door Alarmnummer op 24-04-2004 20:45 ]

[Alarmnummer]

Maar hoe ben je van plan de gebruikers op de hoogte te stellen van de dingen die gebeurt zijn? Een nieuwe user in de chatchannel, user heeft bericht verzonden of is gebanned. Hoe ben je van plan dat op te gaan lossen?

[Kwistnix]

Alarmnummer schreef op 24 april 2004 @ 20:29:

Ik zou die lijst uit je class diagram laten. Een ChatChannel kan meerdere Users bij zich hebben en dat is alles wat je hoeft te weten. Hoe dat intern wordt opgelost (bv met een arraylist) gaat niemand wat aan en moet niet in je uml diagram.

--------

Da's waar. Ik heb even alle overbodige zooi uit m'n orginele diagram weggesneden en hem teruggebracht op context niveau.

http://people.zeelandnet.nl/jelleklap/CSContext.jpg

--------

<knip>
*Handig stukje voorbeeldcode*
</knip>

Bedankt voor de code+uitleg en tips! Ik zal die design patterns zeker bekijken!

[ Voor 3% gewijzigd door Kwistnix op 24-04-2004 20:56 ]

[Kwistnix]

Alarmnummer schreef op 24 april 2004 @ 20:53:
Maar hoe ben je van plan de gebruikers op de hoogte te stellen van de dingen die gebeurt zijn? Een nieuwe user in de chatchannel, user heeft bericht verzonden of is gebanned. Hoe ben je van plan dat op te gaan lossen?

Ik zal nu ik het classdiagram in beeld heb even een CRC sessie starten om te bepalen hoe de verantwoordelijkheden en samenwerkingen tussen de klassen liggen

[Alarmnummer]

FallenAngel666 schreef op 24 april 2004 @ 21:12:
[...]
Ik zal nu ik het classdiagram in beeld heb even een CRC sessie starten om te bepalen hoe de verantwoordelijkheden en samenwerkingen tussen de klassen liggen

Je moet de politiek in gaan

[Kwistnix]

Alarmnummer schreef op 24 april 2004 @ 21:14:
[...]


Je moet de politiek in gaan

Hehehe
Ach, ik ben nog bezig met een Informatica opleiding daar hebben ze me geleerd om CRC sessies te gebruiken als hulpmiddel. Vind het zelf eigenlijk geen slechte methode. Weet alleen niet in hoeverre het nut heeft om dat individueel te doen

[Alarmnummer]

Je moet je afvragen hoe je het wilt gaan doen en daarna kun je wel kijken waar je die functionaliteit gaat onderverderdelen. Je kunt over de sockets naar de client ook weer messages sturen en bij de client ook een thread hebben draaien die de berichten kan aannemen (zoals dat ie gebanned is of dat er een berichtje is geplaatst). Hier hoef je verder niet zo ingewikkeld te doen met threads ed, omdat je dus daar maar 1 extra thread hebt.

[Kwistnix]

Dat laatste context diagram klopt trouwens nog van geen meter volgens mij

• Een client maakt verbinding met de server en stuurt user data.
• De server checkt die data en bepaald de o.a. de role van de user.

De server moet dus of een relatie hebben met de klasse User of de client moet verbinding maken met een default channel op de server. Dit kan natuurlijk geen chatchannel kan zijn, maar een soort van facade.

[ Voor 10% gewijzigd door Kwistnix op 24-04-2004 21:43 ]

[Alarmnummer]

FallenAngel666 schreef op 24 april 2004 @ 21:41:
Dat laatste context diagram klopt trouwens nog van geen meter volgens mij

• Een client maakt verbinding met de server en stuurt user data.
• De server checkt die data en bepaald de o.a. de role van de user.

roles

De server moet dus of een relatie hebben met de klasse User of de client moet verbinding maken met een default channel op de server.

Hoezo? Je kan hem toch automatisch in een kanaal gooien of hem de vraag stellen naar welk kanaal hij wil. Ik zie daar het probleem niet.

Dit kan natuurlijk geen chatchannel kan zijn, maar een soort van facade.

Gebruik aub niet het woord facade *is een design pattern waarmee je een complex systeem kan verbergen achter wat simpelere ingangen*

Ik zou idd ook gaan voor een extra lijst op de server bijhouden met ingelogde maar channelloze users.

[Kwistnix]

Alarmnummer schreef op 24 april 2004 @ 21:47:
[...]

roles


[...]

Hoezo? Je kan hem toch automatisch in een kanaal gooien of hem de vraag stellen naar welk kanaal hij wil. Ik zie daar het probleem niet.


[...]

Gebruik aub niet het woord facade *is een design pattern waarmee je een complex systeem kan verbergen achter wat simpelere ingangen*

Ik zou idd ook gaan voor een extra lijst op de server bijhouden met ingelogde maar channelloze users.

Ik weet dat een facade een design pattern is om een simpele interface te bieden voor een complex (sub)systeem. Maar de taak van die default channel wel vergelijkbaar, omdat dat dan de "interface" van de server zou zijn.

[Alarmnummer]

FallenAngel666 schreef op 24 april 2004 @ 21:53:
[...]

Ik weet dat een facade een design pattern is om een simpele interface te bieden voor een complex (sub)systeem. Maar de taak van die default channel wel vergelijkbaar, omdat dat dan de "interface" van de server zou zijn.

Ik snap niet wat je bedoelt en ik zie niet in hoe zo`n default channel de interactie (waarmee dan ook) eenvoudiger gaat maken. Ik zou dus niet gaan voor een defaultchannel (tenslotte is dat geen echte channel, en je hebt ook absoluut geen behoefte daaraan). Wat is er mis met een of andere list op de server met daarin de channelloze users??

[Kwistnix]

Alarmnummer schreef op 24 april 2004 @ 21:55:
[...]

Ik snap niet wat je bedoelt en ik zie niet in hoe zo`n default channel de interactie (waarmee dan ook) eenvoudiger gaat maken. Ik zou dus niet gaan voor een defaultchannel (tenslotte is dat geen echte channel, en je hebt ook absoluut geen behoefte daaraan). Wat is er mis met een of andere list op de server met daarin de channelloze users??

Nou ik probeer een parallel te trekken met IRC.
Als je met een IRC server verbinding maakt kom je ook eerst in een apart channel, waar de server stats, motd etc. in staan.
Van daar uit join je chatchannels en voer je commands uit om je bijvoorbeeld te registreren.

[ Voor 7% gewijzigd door Kwistnix op 24-04-2004 21:59 ]

[Alarmnummer]

FallenAngel666 schreef op 24 april 2004 @ 21:57:
[...]


Nou ik probeer een parallel te trekken met IRC.
Als je met een IRC server verbinding maakt kom je ook eerst in een apart channel, waar de server stats, motd etc. in staan.
Van daar uit join je chatchannels en voer je commands uit om je bijvoorbeeld te registreren.

KISS (niet verkeerd begrijpen aub)

[Kwistnix]

Alarmnummer schreef op 24 april 2004 @ 21:59:
[...]

KISS (niet verkeerd begrijpen aub)

Keep It Simple <nog iets>

Toch?


In iedergeval, ik ben al een heel eind verder dan ik aan het begin van de avond was, maar toch ben ik er nog lang niet
Ik ga alle info eens tot me door laten dringen en dan zal ik even een nieuw design maken.

[ Voor 38% gewijzigd door Kwistnix op 24-04-2004 22:07 ]

[Alarmnummer]

Keep It Simple Stupid

[Alarmnummer]

Alarmnummer schreef op 24 april 2004 @ 22:08:
Keep It Simple Stupid

Verder ben ik niet zo`n liefhebber om te ontwerpen in uml op dit nivo. Persoonlijk schrijf ik liever code en refactor ik continu. Het voordeel is dat het ontwerp volledig aansluit op de eisen. Het wil trouwens niet zeggen dat je dan niet goed ontwerp, want volgens mij ben ik op got wel een van de grootste zeikers op het gebied van correct ontwerp. Een ontwerp moet organisch groeien en kan je niet vergelijken met het bouwen van een huis. Waarom dacht je dat iteratieve methodologieen (rup xp etc) zo populair zijn? Omdat ze inzien dat je niet alles eerst kan ontwerpen en daarna alles kan schrijven.

[Kwistnix]

Class Diagram (context)

Ik ga voor dit diagram eens kijken of ik het messagesysteem tussen de classes voor elkaar kan krijgen. Ik wel als ik daarmee klaar ben of, wanneer ik tegen problemen aanloop

P.s. ik heb me nog even verdiept in de user en roles en ik stuitte al snel op het RBAC pattern. Dat leek mij een geschikte oplossing voor deze situatie en dat heb ik dus maar toegepast

[ Voor 3% gewijzigd door Kwistnix op 24-04-2004 23:55 ]

[Kwistnix]

Alarmnummer schreef op 24 april 2004 @ 22:12:
[...]


Verder ben ik niet zo`n liefhebber om te ontwerpen in uml op dit nivo. Persoonlijk schrijf ik liever code en refactor ik continu. Het voordeel is dat het ontwerp volledig aansluit op de eisen. Het wil trouwens niet zeggen dat je dan niet goed ontwerp, want volgens mij ben ik op got wel een van de grootste zeikers op het gebied van correct ontwerp. Een ontwerp moet organisch groeien en kan je niet vergelijken met het bouwen van een huis. Waarom dacht je dat iteratieve methodologieen (rup xp etc) zo populair zijn? Omdat ze inzien dat je niet alles eerst kan ontwerpen en daarna alles kan schrijven.

Volledige aansluiting op de eisen (voor zover dat geen illusie is) kan je ook bereiken wanneer in een zo vroeg mogelijk stadium de quality attributes in het design integreert (zei de newbie ).

Ik heb toevallig vorige week een duo-presentatie over QA's moeten geven en daarin is o.a. een model besproken waarmee je dat kan bereiken. Best aardig.

[Alarmnummer]

FallenAngel666 schreef op 25 april 2004 @ 00:07:
[...]
Volledige aansluiting op de eisen (voor zover dat geen illusie is) kan je ook bereiken wanneer in een zo vroeg mogelijk stadium de quality attributes in het design integreert (zei de newbie ).

Kwaliteits attributen zijn maar een onderdeel van het ontwerp. Je ontwerp moet zo goed mogelijk aansluiten op het probleem en niet andersom. Daarom is het imho niet verstandig om alleen te ontwerpen maar ook emperisch te testen. Daarmee kun je testen of je ontwerp echt wel goed genoeg is. Verder doe je tijdens de implementatie nieuwe inzichten op, en dat kan je meteen laten reflecteren in je ontwerp. Persoonlijk ga ik voor lastige/grote problemen eerst een beetje prototypen zodat ik het probleem goed op me in kan laten werken. Misschien dat ik daar een uitzondering in ben hoor, maar met een paar regeltjes code kan ik voor mezelf ontzettend veel duidelijk maken. Vaak meer dan aan de hand van een aantal droge schema`s.

En nogmaals, het wil niet zeggen dat er geen abstracte modellen (ontwerp/architectuur) moeten zijn waarin je over allerlei kwaliteitsattributen van je systeem kan redereren zoals performance, security etc.

check anders mijn afstudeerverslag eens:
http://www.alarmnummer.net
Daar staat ook praatje in over architectuur en modellen.

[Alarmnummer]

En hoe staat het met je server?

[Kwistnix]

Alarmnummer schreef op 25 april 2004 @ 21:45:
En hoe staat het met je server?

Ik heb er vandaag niet veel aan kunnen doen.
Heb wel een paar use cases uitgewerkt en nog wat aangepast aan het class diagram. Morgen ga ik waarschijnlijk weer serieus verder.
Ik heb twee les vrije weken dus ik kan er nu aardig wat tijd aan besteden (hoewel ik ook nog aan 2 projecten voor school moet werken en die gaan wel voor natuurlijk ).

[SiErRa]

Om wat meer over sockets/threading te leren heb ik ooit eens een java irc client geschreven (nooit helemaal afgemaakt). De irc rfc is misschien wel leuk om eens door te lezen, om wat ideeen op te doen over hoe het allemaal werkt.

[hobbit_be]

de topic NIO Sockets zijn hier nog niet gevallen? Om nu in Java te beginnen zonder NIO is absurd.

Gebruik of niet gebruik van threads zou nooit in een class mogen steken: ie nooit afleiden van Runnable (tenzij mini-projectje). Wel een worker class die interfaces aanroept

[Kwistnix]

hobbit_be schreef op 26 april 2004 @ 09:46:
de topic NIO Sockets zijn hier nog niet gevallen? Om nu in Java te beginnen zonder NIO is absurd.

Ik heb al naar de New I/O library gekeken

Gebruik of niet gebruik van threads zou nooit in een class mogen steken: ie nooit afleiden van Runnable (tenzij mini-projectje). Wel een worker class die interfaces aanroept

Leg uit.

[ Voor 4% gewijzigd door Kwistnix op 26-04-2004 13:59 ]

[hobbit_be]

ie je maakt je "handler" van je data 100% interface based.

IRequest dan maak je eventueel later nog x-threads met y-aantal "delegate" die ieder een IRequest aan roepen.


Sockets -> (threads of ni) -> IRequest(s).

[Verwijderd]

hmm, het plaatje van de klassendiagram werkt niet.
Zou je die ff kunnen fixxen, zou em wel is willen zien.

bvd.

[Kwistnix]

Verwijderd schreef op 27 april 2004 @ 09:47:
hmm, het plaatje van de klassendiagram werkt niet.
Zou je die ff kunnen fixxen, zou em wel is willen zien.

bvd.

Sorry, die had ik al weggehaald

Het context diagram:

http://people.zeelandnet.nl/jelleklap/Context.jpg