[algemeen] Gebruikers snel en efficient op de hoogte stellen

vrijdag 19 augustus 2005 11:27

Admin Devschuur®

^ Romeinse Ⅲ ja!

zmn schreef op vrijdag 19 augustus 2005 @ 11:22:
E-mail lijkt mij de beste optie, desnoods zou je serverside wel wat kunnen maken met een RSS feed en iedereen een RSS-reader laten installeren, dit is ook niet gigantisch zwaar voor je server

RSS is ook gewoon een poll (die overigens vaak niet veel vaker dan 4x per uur wordt gepolled) en dan ga je dus al met je max. 2 minuten vertraging.
ICQ is ook gewoon een open socket volgens mij?

kroeske schreef op vrijdag 19 augustus 2005 @ 11:23:
je zou met een client server structuur kunnen werken en een klein systeempje op te zetten waarbij de clients naar een bepaalde poort luisteren en dat je de server indien nodig een bericht naar die poort laat sturen. maar dat is een stuk meer werk dan het gebruik van icq/email/jabber whatever

That's more like it, hoewel dat dan wel weer in de Firewall aangepast zal dienen te worden.

Reptile209 schreef op vrijdag 19 augustus 2005 @ 11:24:
Als iedere client een servertje draait, kan jouw server in 2 min wellicht 1000 connecties maken om de lokale servertjes een bericht te sturen. Krijg je wel gedonder met firewalls, software installeren, etc. en je server moet een lijst met IP's bijhouden en af kunnen werken.

Kwestie van bijhouden wie er ingelogged is (en welk IP dus).

Reptile209 schreef op vrijdag 19 augustus 2005 @ 11:24:
Iets als ICQ / MSN lijkt me nog het meest efficient omdat de server niet hoeft te wachten of het bericht aankomt. Bij het opbouwen van een verbinding naar een client zal dat een grote vertragende factor zijn.

Nu is de kwaliteit doorgaans niet erg slecht van die netwerken, maar als je requirement is dat je Max. 2 minuten vertraging op 1000(-en?) berichten mag hebben weet ik zo net nog niet of je dit gaat redden.

Zowieso is 3rd party (ICQ/Jabber/MSN/whatever) niet echt aan te raden lijkt me. Je bent dan teveel afhankelijk van die partijen. Email is natuurlijk helemaal bud, omdat je dan niet weet OF het bericht wel is aangekomen (en het lijkt me dat je dit wel wil weten).
Je zult misschien iets duidelijker moeten zijn in je requirements en wellicht de "capaciteiten" van de gebruikers (als in: kunnen ze doorgaans wel zelf hun firewall open gooien als nodig) etc.

chem schreef op vrijdag 19 augustus 2005 @ 11:27:
IRC ?

Gewoon een 'blinde' client bouwen, en je eigen protocol bouwen bovenop het irc protocol; je hele private messaging, passwords, notifications, dialogen, bestandsuitwisseling etc. zijn dan al gedefinieerd en beschikbaar.

En dat is dan weer wél een leuke suggestie die het overwegen waard is lijkt me $_/-\o_$

[ Voor 20% gewijzigd door RobIII op 19-08-2005 11:30 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

chem

Reist de wereld rond

IRC ?

Gewoon een 'blinde' client bouwen, en je eigen protocol bouwen bovenop het irc protocol; je hele private messaging, passwords, notifications, dialogen, bestandsuitwisseling etc. zijn dan al gedefinieerd en beschikbaar.

Klaar voor een nieuwe uitdaging.

vrijdag 19 augustus 2005 11:31

Acties:

GlowMouse

chem schreef op vrijdag 19 augustus 2005 @ 11:27:
IRC ?

Gewoon een 'blinde' client bouwen, en je eigen protocol bouwen bovenop het irc protocol; je hele private messaging, passwords, notifications, dialogen, bestandsuitwisseling etc. zijn dan al gedefinieerd en beschikbaar.

Dan moet je vertrouwen op een andere server, want zelf een server opzetten kost weer veel connecties. IRC servers zijn niet altijd 100% betrouwbaar (oa netsplits).

vrijdag 19 augustus 2005 11:33

Acties:

vrijdag 19 augustus 2005 11:36

GC.Collect(head);

Wel pollen, als je de clients laat pollen met een interval van 2 minuten zal 1000 client verdeelt zijn over 2 minuten, als het perfect verdeelt is het elke 0,12 seconden een poll. Dit is voor de server nou niet echt belastend. Een poll message hoeft niet veel informatie te bevatten en zijn dus kleine pakketjes.

Om de clients goed te verdelen, stuur je hun gewoon een nieuwe interval terug. Je zults ze op die manier nooit perfect verdelen, maar het komt iig wel in de richting.

Een server client-side opzetten is voor de firewall bij de client niet zo leuk. En ze moeten wellicht weer porten forwarden enzo, dit zijn imho grootte nadelen.

[ Voor 39% gewijzigd door pjvandesande op 19-08-2005 11:36 ]

Acties:

TheRookie

Nu met R1200RT

Laten pollen met een interval van 5 minuten doet de requirement van 'binnen 2 minuten iedereen op de hoogte brengen' weer teniet ...

[edit]Niet stiekum de post editen als ik aan 't reply-en ben

[ Voor 24% gewijzigd door TheRookie op 19-08-2005 11:37 ]

vrijdag 19 augustus 2005 11:36

Acties:

vrijdag 19 augustus 2005 11:40

Admin Devschuur®

^ Romeinse Ⅲ ja!

GlowMouse schreef op vrijdag 19 augustus 2005 @ 11:31:
[...]

Dan moet je vertrouwen op een andere server, want zelf een server opzetten kost weer veel connecties. IRC servers zijn niet altijd 100% betrouwbaar (oa netsplits).

Je eigen IRC draaien kan ook nog altijd.

questa schreef op vrijdag 19 augustus 2005 @ 11:33:
Wel pollen, als je de clients laat pollen met een interval van 5 minuten zal 1000 client verdeelt zijn over 10 minuten, als het perfect verdeelt is het elke 0.6 seconden een poll. Dit is voor de server nou niet echt belastend. Een poll message hoeft niet veel informatie te bevatten en zijn dus kleine pakketjes.

10:35:21 JO! Client=1224986
10:35:22 JO! Client=1224986
10:35:23 JO! Client=1224986
10:35:24 JO! Client=1224986
10:35:25 JO! Client=1224986

Maar denk wel aan die max. van 2 minuten waar de TS om vraagt. En als je "op de groei" wil bouwen (als in: 1000 wordt later misschien wel 100.000) zul je toch even verder moeten denken.

questa schreef op vrijdag 19 augustus 2005 @ 11:33:
Een server client-side opzetten is voor de firewall bij de client niet zo leuk. En ze moeten wellicht weer porten forwarden enzo, dit zijn imho grootte nadelen.

Eensch is. Behalve dan dat het grote nadelen zijn, niet grootte

[ Voor 20% gewijzigd door RobIII op 19-08-2005 11:38 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

vrijdag 19 augustus 2005 11:44

GC.Collect(head);

TheRookie schreef op vrijdag 19 augustus 2005 @ 11:36:
Laten pollen met een interval van 5 minuten doet de requirement van 'binnen 2 minuten iedereen op de hoogte brengen' weer teniet ...

[edit]Niet stiekum de post editen als ik aan 't reply-en ben

Wat bedoel je?

RobIII schreef op vrijdag 19 augustus 2005 @ 11:36:
[...]

Je eigen IRC draaien kan ook nog altijd.

[...]

10:35:21 JO! Client=1224986
10:35:22 JO! Client=1224986
10:35:23 JO! Client=1224986
10:35:24 JO! Client=1224986
10:35:25 JO! Client=1224986

Maar denk wel aan die max. van 2 minuten waar de TS om vraagt. En als je "op de groei" wil bouwen (als in: 1000 wordt later misschien wel 100.000) zul je toch even verder moeten denken.

Als je 100.000 klanten hebt, heb je ook weer poen voor een extra server.

[...]

Eensch is. Behalve dan dat het grote nadelen zijn, niet grootte

Freak

Acties:

Glimi

Designer Drugs

RobIII schreef op vrijdag 19 augustus 2005 @ 11:36:
Maar denk wel aan die max. van 2 minuten waar de TS om vraagt. En als je "op de groei" wil bouwen (als in: 1000 wordt later misschien wel 100.000) zul je toch even verder moeten denken.

Let op, de gebruiker stelt dat bij 1000 gebruikers de vertraging maximaal 2 minuten mag zijn. Als de boel dus opschaalt, dan dan de vertraging wel wat groter worden. Stel we noemen even 3 minuten.
100 000 / 180 = 555 polls per seconde. Dat zou goed moeten gaan met de hardware van nu, mocht het toch problemen geven, dan gooi je er toch nog een machine tegen aan?

vrijdag 19 augustus 2005 12:12

Acties:

vrijdag 19 augustus 2005 12:33

Admin Devschuur®

^ Romeinse Ⅲ ja!

Glimi schreef op vrijdag 19 augustus 2005 @ 11:44:
[...]
Let op, de gebruiker stelt dat bij 1000 gebruikers de vertraging maximaal 2 minuten mag zijn. Als de boel dus opschaalt, dan dan de vertraging wel wat groter worden. Stel we noemen even 3 minuten.
100 000 / 180 = 555 polls per seconde. Dat zou goed moeten gaan met de hardware van nu, mocht het toch problemen geven, dan gooi je er toch nog een machine tegen aan?

Ik vind de redenatie "Meer gebruikers, dus langere vertraging mag" nogal een rare redenatie. Wie zegt dat er door die app niet binnen 2 minuten moet worden gereageerd omdat er anders ergens een fabriek in de soep loopt? (Nu lijkt me dat bij 1000+ gebruikers niet echt het geval, maar dan nog...). Waarvoor de TS die 2 minuten specificeert is niet duidelijk, maar je mag niet zomaar aannemen dat het bij meer gebruikers dan automatisch meer vertaging mag toestaan. Dan zal de TS eerst iets moeten uitwijden lijkt me.

Edit: Ik lees net de topicstart opnieuw en het is inderdaad op meer manieren te interpreteren. Je zou dus wel gelijk kunnen hebben. Het is maar net hoe je het leest:

"bij 1000 gebruikers mag de maximale vertraging (dat een bericht bij de gebruiker aan komt) 2 minuten zijn."

Bij 1000 gebruikers mag de vertraging max. 2 minuten zijn, en bij 10 dus ook (maar waarschijnlijk minder). En bij 100.000 dus ook.
Bij 1000 gebruikers mag de vertraging max. 2 minuten zijn, en bij 2000 dus 4 minuten.

[ Voor 25% gewijzigd door RobIII op 19-08-2005 12:16 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

Verwijderd

Topicstarter

Dank jullie voor de replies, ik zal proberen een aantal onduidelijkheden weg te nemen:

- ik zou willen gaan voor de meest efficientste oplossing, dus een vertraging van 2 minuten bij 1000 gebruikers is oke, maar als er een oplossing is die een vertraging van 2 minuten bied bij 2000 gebruikers dan is dat nog beter. De maximale vertraging van 2 minuten bij 1000 gebruiker kan daarom beter gezien worden als onder grens.
- ik ben niet zo thuis in IRC, maar als ik het goed begrijp stuur ik dan een berichtje naar een irc server en de gebruiker met een omgebouwde client ziet dat berichtje dan. Maar zou de beheerder van de irc server dat leuk vinden? (ivm met zijn eigen serverbelasting)
- een server aan de clientside is in principe een mogelijkheid die ik niet uitsluit, maar over mogelijke problemen mbt firewalls/routers/proxies maak ik me wel zorgen.

Hopelijk is het nu wat duidelijk.

[edit]
Waar ik net op kwam is een variatie op email: ik stuur een email in een bepaald formaat ( time|gebeurtenis ) met een bepaald subject ("voor: [myprogram]"). Dan maak ik een klein client programmatje die om de minuut controleert of er een email is met subject "voor: [myprogram]". Zo ja, dan haalt ie de email op, en geeft hij een bericht weer.

Een nadeel is wel dat de gebruiker een filter moet aanmaken in z'n email programma dat hij email met subject "voor: [myprogram]" naar de trash stuurt.

Hmm, een ander nadeel is dat de gebruiker de email ophaald met z'n mailclient voordat m'n programmatje de email heeft gezien..

[ Voor 27% gewijzigd door Verwijderd op 19-08-2005 12:41 ]

vrijdag 19 augustus 2005 12:37

Acties:

Glimi

Designer Drugs

RobIII schreef op vrijdag 19 augustus 2005 @ 12:12:
Ik vind de redenatie "Meer gebruikers, dus langere vertraging mag" nogal een rare redenatie. Wie zegt dat er door die app niet binnen 2 minuten moet worden gereageerd omdat er anders ergens een fabriek in de soep loopt?

Bij 2 min op 100 000 gebruikers komt je op ~840 polls p/s. Het ligt maar net aan hoe de infrastructuur is en hoe de data is om te zeggen of dat een hoge load geeft of niet.
Echter de indicatie van 1000 gebruikers geeft bij mij al een beetje aan dat de applicatie niet voor 100 000 gebruikers gestoelt is. Natuurlijk is het zo dat dat op een gegeven ogenblik de vraag ernaar kan zijn en dan is het fijn dat het kan, maar zo'n vraag zal er niet direct zijn en dus is er tijd om te groeien (danwel in de hardware of op andere vlakken)

vrijdag 19 augustus 2005 12:39

Acties:

vrijdag 19 augustus 2005 13:02

GC.Collect(head);

Verwijderd schreef op vrijdag 19 augustus 2005 @ 12:33:
...maar als er een oplossing is die een vertraging van 2 minuten bied bij 2000 gebruikers dan is dat nog beter. De maximale vertraging van 2 minuten bij 1000 gebruiker kan daarom beter gezien worden als onder grens.

2000 gebruikers en een interval van 2 minuten moet makkelijk kunnen.

- ik ben niet zo thuis in IRC, maar als ik het goed begrijp stuur ik dan een berichtje naar een irc server en de gebruiker met een omgebouwde client ziet dat berichtje dan. Maar zou de beheerder van de irc server dat leuk vinden? (ivm met zijn eigen serverbelasting)

Waarom schrijf je niet gewoon je eigen protocol. Ik weet niet om wat voor messages het gaat, maar zijn het echt alleen maar messages en hoeven er geen bestanden uitgewisseld te worden dan kun je zelf een simple protocol bedenken waarbij je de overhead beperkt.

- een server aan de clientside is in principe een mogelijkheid die ik niet uitsluit, maar over mogelijke problemen mbt firewalls/routers/proxies maak ik me wel zorgen.

Deze mogelijkheid zou ik wel uitsluiten. Want een klant moet ze inderdaad ze firewalls etc. instellen hiervoor. Dit zou ik altijd proberen te vermijden.

Acties:

Verwijderd

UDP pakketjes versturen?
+ connectionless
+ lightweight
+ onafhankelijk van externe partijen
- unreliable (dus je weet niet zeker of je berichtje ontvangen is)
- evt. firewall problemen (maar dat heb je met alles)

vrijdag 19 augustus 2005 13:11

Acties:

vrijdag 19 augustus 2005 13:24

Ondersteunt het netwerk multicast? Heb je al eens naar een group communication system zoals Spread gekeken?

[ Voor 11% gewijzigd door jochemd op 19-08-2005 13:12 ]

Acties:

Infinitive

Verwijderd schreef op vrijdag 19 augustus 2005 @ 13:02:
UDP pakketjes versturen?

Als er verder nog communicatie plaats vind tussen client en server, zou ik een combinatie van beide doen:

server stuurt udp-pakketjes en de clients doen vervolgens een tcp/ip verbinding terug voor de rest van het proces. Als je vervolgens voor clients die maar niet terug willen connecten aan resends van het udp-pakketje doet ben je ook van de onreliability af: je alert data hoeft niet groot te zijn zodat het altijd in één pakketje past en dan weet je dat als de client binnen twee minuten met resents dat pakketje niet ontvangen had, dat het met tcp/ip ook niet gelukt zou zijn.

Je zult op deze manier wel tegen flinke firewall problemen lopen. Dat doe je vrijwel altijd wel, maar het instellen van firewalls/routers aan de kant van de client voor inkomend udp verkeer is wel wat zwaardere consequenties (denk bijv. aan NAT-routers) dan een uitgaande connectie laten toestaan.

Ik weet niet in hoeverre ICQ via programma's aan te spreken is? Als dat eenvoudig gaat, zou ik eerder daar voor kiezen. Laat het ICQ netwerk het maar uitzoeken

putStr $ map (x -> chr $ round $ 21/2 * x^3 - 92 * x^2 + 503/2 * x - 105) [1..4]

vrijdag 19 augustus 2005 13:53

Acties:

vrijdag 19 augustus 2005 14:21

Admin Devschuur®

^ Romeinse Ⅲ ja!

Verwijderd schreef op vrijdag 19 augustus 2005 @ 12:33:
- ik ben niet zo thuis in IRC, maar als ik het goed begrijp stuur ik dan een berichtje naar een irc server en de gebruiker met een omgebouwde client ziet dat berichtje dan. Maar zou de beheerder van de irc server dat leuk vinden? (ivm met zijn eigen serverbelasting)

Zoals ik al aangaf kun je natuurlijk ook je eigen IRC server draaien.

Verwijderd schreef op vrijdag 19 augustus 2005 @ 12:33:
Waar ik net op kwam is een variatie op email: ik stuur een email in een bepaald formaat ( time|gebeurtenis ) met een bepaald subject ("voor: [myprogram]"). Dan maak ik een klein client programmatje die om de minuut controleert of er een email is met subject "voor: [myprogram]". Zo ja, dan haalt ie de email op, en geeft hij een bericht weer.

Een nadeel is wel dat de gebruiker een filter moet aanmaken in z'n email programma dat hij email met subject "voor: [myprogram]" naar de trash stuurt.

Hmm, een ander nadeel is dat de gebruiker de email ophaald met z'n mailclient voordat m'n programmatje de email heeft gezien..

nog wat nadelen van email:
* Je bent afhankelijk van diverse mailservers en dus onberekenbare vertragingen etc. 2 minuten is meestal goed te doen, maar op 1000 clients zitten er geheid clients tussen die meer dan 2 minuten nodig hebben om die mail te ontvangen
* Doorgaans wordt mail ook gepopped (en dus een poll). Alleen belast je nu niet je eigen server maar die van de providers. En die zullen dat ook niet leuk vinden als iedereen iedere minuut gaat poppen
* Van E-mail weet je niet zeker of deze aan komt (zoals ik al eerder zei)
* Mail clients (als in Outlook e.d.) zouden idd "per ongeluk" je bericht al kunnen poppen voordat je app dat doet (zoals je zelf aangeeft)

Hoe dan ook, E-mail is NOT the way to go IMHO

Een korte samenvatting:
Ga je voor "pollen" (op wat voor manier dan ook) dan voorkom je (de meeste) problemen met firewalls etc. Ga je "luisteren" dan kom je "firewall problemen" geheid tegen. Ga je voor 3rd party oplossingen (ICQ/IRC's van anderen enz) dan ben je van hen afhankelijk. Doe je het zélf (eigen protocol/server) dan ben jij de baas.

[ Voor 11% gewijzigd door RobIII op 19-08-2005 13:55 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

Verwijderd

Nog een idee: een soort van decentralized netwerk idee.
- Iedere client is tegelijk server.
- Wanneer een client voor de eerste keer connect, maakt het verbinding met de server van TS.
- De server van TS geeft een aantal IP adressen van andere connectable clients. Wanneer de server van TS minder dan X client connecties heeft, dan blijft de connectie bestaan. Anders wordt de connectie weer verbroken.
- De client probeert een verbinding te maken met andere connectable clients
- Zo lang het netwerk in de lucht is, wisselen de clients onderling gegevens uit. Als er dan een client uitvalt, kunnen de clients die daarmee verbonden waren snel een nieuwe verbinding maken.
- Iedere client probeert 1 keer per X minuten/uur een verbinding te maken met de hoofd-server van TS. Wanneer deze server tijdelijk uit het netwerk wordt gehaald, hersteld het netwerk zich zodra de server weer terug is.
- Zodra de server van TS een bericht het netwerk op stuurt (inclusief messageID en/of timestamp), wordt dit bericht direct over het hele netwerk verstuurd. Zodra een client voor de 2e keer hetzelfde bericht krijgt, kan het in principe dus genegeerd worden.

vrijdag 19 augustus 2005 14:28

Acties:

alienfruit

the alien you never expected

Ik heb ook een vergelijkbaar probleem, maar dan de kant van de systembeheerders. Ik wil ook berichten naar gebruikers van een online spel sturen, alleen normaal zou je denken dit is geen probleem. Alleen de doelgroep zijn ambtenaren, waarbij er dus problemen onstaan bij het gebruik van een programmatje (geen admin-rechten, nieuwe programma te installeren door beheer, gat in de firewall e.d.) dat een bericht popupt a la MSN (iets wat niet mag gedraaid worden). Maar ja, hoe krijg je dan zo'n bericht er doorheen, beetje probleematisch.

[ Voor 10% gewijzigd door alienfruit op 19-08-2005 14:29 ]

vrijdag 19 augustus 2005 14:28

Acties:

Anders

SMS.

Heb je geen problemen met client-software, poll-belasting, mensen met wisselende werkplekken, mobiele internetters etc etc etc etc.

Ik spoor veilig of ik spoor niet.

vrijdag 19 augustus 2005 14:42

Acties:

Janoz

Moderator Devschuur®

!litemod

Alle opties waarin iets wordt voorgesteld waarbij de client zelf een server is (ie inkomende verbindingen moet accepteren) zijn imho behoorlijk uit te sluiten. Dat soort oplossingen werken bij de meeste clients niet. Niet alleen firewalls zijn een probleem, maar ook (wireless) routers (tegenwoordig vaker regel dan uitzondering) en andere NAT oplossingen. Daarnaast zal in een NAT omgeving maar 1 persoon tegelijk gebruik kunnen maken van het systeem. Veel mensen willen, kunnen of mogen dit soort dingen niet aanpassen.

Wordt het trouwens een losse applicatie die de client moet instaleren, is het een webbased iets waarop eventueel een actief iets (applet/flash/activeX) draait, of staat dat nog helemaal niet vast?

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

vrijdag 19 augustus 2005 15:40

Acties:

MSalters

Waarom mag je eigenlijk geen sockets openhouden? 1000 open sockets is toch niet veel? Beperk desnoods de inkomende buffers tot 1 MTU, die gebruik je toch niet.

Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein

vrijdag 19 augustus 2005 15:50

Acties:

vrijdag 19 augustus 2005 16:08

Als de client geen server mag zijn, dan moet de client wel pollen. Het makkelijkst lijkt me dan om een bestaande infrastructuur te gebruiken, namelijk instant messaging. In het bijzonder Jabber, want daar is eenvoudig tegen aan te programmeren.

Of je ook messages kan sturen naar gebruikers zonder dat je client (die de messages stuurt) een verbinding moet onderhouden naar de gebruikers' jabber server weet ik niet zo zeker.

Acties:

vrijdag 19 augustus 2005 16:11

GC.Collect(head);

MSalters schreef op vrijdag 19 augustus 2005 @ 15:40:
Waarom mag je eigenlijk geen sockets openhouden? 1000 open sockets is toch niet veel? Beperk desnoods de inkomende buffers tot 1 MTU, die gebruik je toch niet.

Omdat Infinitive heb UDP adviceerd en de TS dit advies ook gaat opvolgen

Anyway, ik zou ook geen protocollen als IRC/ICQ etc gaan gebruiken. Gewoon zelf een server opzetten en de clients laten pollen. Zoals meerderen al hebben aangegeven is dit niet echt zwaar voor de server. Zeker niet als je UDP gebruikt met kleine poll-pakketjes. Dan zie ik de problemen eigelijk niet.

Sendy schreef op vrijdag 19 augustus 2005 @ 15:50:
Als de client geen server mag zijn, dan moet de client wel pollen. Het makkelijkst lijkt me dan om een bestaande infrastructuur te gebruiken, namelijk instant messaging. In het bijzonder Jabber, want daar is eenvoudig tegen aan te programmeren.

Of je ook messages kan sturen naar gebruikers zonder dat je client (die de messages stuurt) een verbinding moet onderhouden naar de gebruikers' jabber server weet ik niet zo zeker.

Wat is het voordeel van zo'n overhead? Je kunt toch beter zelf gewoon een klein protocoll in elkaar flansen? Jabber is niet connectionless gok ik.

[ Voor 35% gewijzigd door pjvandesande op 19-08-2005 16:11 ]

Acties:

vrijdag 19 augustus 2005 16:12

Admin Devschuur®

^ Romeinse Ⅲ ja!

questa schreef op vrijdag 19 augustus 2005 @ 16:08:
[...]

Omdat Infinitive heb UDP adviceerd en de TS dit advies ook gaat opvolgen

Anyway, ik zou ook geen protocollen als IRC/ICQ etc gaan gebruiken. Gewoon zelf een server opzetten en de clients laten pollen. Zoals meerderen al hebben aangegeven is dit niet echt zwaar voor de server. Zeker niet als je UDP gebruikt met kleine poll-pakketjes. Dan zie ik de problemen eigelijk niet.

Behalve dat je met UDP nooit weet of het pakketje aan komt. En ik weet niet of dat "kritiek" is voor de applicatie.
Tevens is het denk ik ook zaak om te weten HOE VAAK de berichten vanuit de server verstuurd gaan worden (bij benadering). Zijn dat er 2 per week? Of 200 per uur?

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

vrijdag 19 augustus 2005 16:19

GC.Collect(head);

RobIII schreef op vrijdag 19 augustus 2005 @ 16:11:
[...]

Behalve dat je met UDP nooit weet of het pakketje aan komt. En ik weet niet of dat "kritiek" is voor de applicatie.
Tevens is het denk ik ook zaak om te weten HOE VAAK de berichten vanuit de server verstuurd gaan worden (bij benadering). Zijn dat er 2 per week? Of 200 per uur?

De client blijft net zolang UDP pakketjes schieten totdat hij een response heeft van de server.

Acties:

JJvG

Variatie op het thema e-mail: Maak een gratis e-mailadres aan (Hotmail, Gmail, Yahoo, whatever) en bouw een kleine pop-checker die je als client installeert en elke minuut het e-mailadres laat checken. Kun je in je e-mail-subject de melding zetten en die m.b.v. je programma uitlezen. Bijvoorbeeld een XML subject dat je parsed of gewoon comma-separated en dan omklussen naar een 2-dimensionale array.
Edit: en dat het subject tonen in een pop-upje a-la-messenger.

[ Voor 8% gewijzigd door JJvG op 19-08-2005 16:20 ]

vrijdag 19 augustus 2005 16:20

Acties:

vrijdag 19 augustus 2005 16:25

questa schreef op vrijdag 19 augustus 2005 @ 16:08:
[...]

Omdat Infinitive heb UDP adviceerd en de TS dit advies ook gaat opvolgen

Anyway, ik zou ook geen protocollen als IRC/ICQ etc gaan gebruiken. Gewoon zelf een server opzetten en de clients laten pollen. Zoals meerderen al hebben aangegeven is dit niet echt zwaar voor de server. Zeker niet als je UDP gebruikt met kleine poll-pakketjes. Dan zie ik de problemen eigelijk niet.

[...]

Wat is het voordeel van zo'n overhead? Je kunt toch beter zelf gewoon een klein protocoll in elkaar flansen? Jabber is niet connectionless gok ik.

Het voordeel lijkt me duidelijk. Makkelijk programmeren. Bestaande infrastructuur. Als je zelf iets bouwt ben je eerst bezig met bugs inbouwen, later met het weer verwijderen daarvan. Verder, je moet een programma hebben dat de boodschap op het scherm toont. Jabber is cross-platform, en er zijn zat clients. Voor ieder wat wils. Ga dat maar eens zelf programmeren. En last but not least, een jabber client is ook nog voor iets andere te gebruiken. Niet weer een nutteloos programma erbij.

Maar als ik het goed heb, de TS heeft nog helemaal niet verteld wie de ontvangers zijn van de melding; da's dus nog een beetje speculeren.

Acties:

vrijdag 19 augustus 2005 16:26

GC.Collect(head);

Sendy schreef op vrijdag 19 augustus 2005 @ 16:20:
[...]

Het voordeel lijkt me duidelijk. Makkelijk programmeren. Bestaande infrastructuur. Als je zelf iets bouwt ben je eerst bezig met bugs inbouwen, later met het weer verwijderen daarvan. Verder, je moet een programma hebben dat de boodschap op het scherm toont. Jabber is cross-platform, en er zijn zat clients. Voor ieder wat wils. Ga dat maar eens zelf programmeren. En last but not least, een jabber client is ook nog voor iets andere te gebruiken. Niet weer een nutteloos programma erbij.

Maar als ik het goed heb, de TS heeft nog helemaal niet verteld wie de ontvangers zijn van de melding; da's dus nog een beetje speculeren.

Zoveel programmeer werk is dat niet zo'n simple broadcast protocolletje en het jabber protocoll of welk onder protocoll dan ook zou je intregreren in je client application dus je krijgt er sowieso geen nutteloos programma bij.

Acties:

vrijdag 19 augustus 2005 16:32

Admin Devschuur®

^ Romeinse Ⅲ ja!

Sendy schreef op vrijdag 19 augustus 2005 @ 16:20:
[...]
Het voordeel lijkt me duidelijk. Makkelijk programmeren. Bestaande infrastructuur. Als je zelf iets bouwt ben je eerst bezig met bugs inbouwen, later met het weer verwijderen daarvan.

Wat is dat nou voor argument? Dan kun je net zo goed niet gaan programmeren. Bugs "inbouwen" doe je altijd, ongeacht wat je programmeert (natuurlijk doen devvers het wel ongewild, maar dat is een ander verhaal). En een client-server bouwen met wat sockets is echt wel in een paar regels code te doen, een beetje programmeur schrikt daar niet voor terug. En ALS er bugs in zitten kun je ze zélf oplossen, dat heb je bij 3rd party frameworks niet (ja ja, open source my ass, niemand die dat zelf gaat zitten aanpassen; iedereen gaat op de "officiële" patch zitten wachten, en dan maar duimen dat het niet te lang duurt).

Sendy schreef op vrijdag 19 augustus 2005 @ 16:20:
Verder, je moet een programma hebben dat de boodschap op het scherm toont. Jabber is cross-platform, en er zijn zat clients.

Zoals ik de posts van de TS lees is de TS bezig met een APP die onder andere een message moet tonen. Anders kon 'ie net zo goed meteen MSN gebruiken lijkt me (of welke andere messenger dan ook). Die berichten zijn dus maar een (klein?) onderdeel van de App.

Sendy schreef op vrijdag 19 augustus 2005 @ 16:20:
Voor ieder wat wils. Ga dat maar eens zelf programmeren. En last but not least, een jabber client is ook nog voor iets andere te gebruiken. Niet weer een nutteloos programma erbij.

Het is wél nutteloos als de gebruiker het moet installeren puur om die berichten te ontvangen. De gemiddelde gebruiker gaat echt niet over op Jabber dan, maar blijft lekker op zijn MSN zitten. (Daarmee zeg ik niks over Jabber of MSN, maar puurt dat het de gebruiker worst zal zijn, en hij/zij naar alle waarschijnlijkheid MSN gewend is en liever gebruikt. Dat Jabber misschien wel of niet beter is zeg ik dus niet). Overigens implementeer je (als je het dan toch doet) de communicatie dan alleen in je eigen app en ga je er geen complete Jabber client voor zitten installeren. Je gebruikt alleen de juiste componenten ervan en "wrapped" ze in je eigen app).

Sendy schreef op vrijdag 19 augustus 2005 @ 16:20:
Maar als ik het goed heb, de TS heeft nog helemaal niet verteld wie de ontvangers zijn van de melding; da's dus nog een beetje speculeren.

De eindgebruikers

[ Voor 18% gewijzigd door RobIII op 19-08-2005 16:31 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

ThunderNet

Flits!

Is het niet mogelijk om een soort piramide systeem te maken?

De server stuurt een bericht naar de kleinere servers/bepaalde workstations op de afdelingen.
En op de afdelingen zelf, laat je de berichten/polling doen, door de lokale 'servers'

Op deze manier heb je geen last dat je server de connecties niet aan kan.

Heb je liever vooraf, of achteraf, dat ik zeg dat ik geen flauw idee heb wat ik doe?

vrijdag 19 augustus 2005 16:34

Acties:

vrijdag 19 augustus 2005 16:39

RobIII >

Nou, je bent een beetje onredelijk. Er is een verschil tussen het programmeren van een protocol met bijpassende client en server en het sturen van wat XML naar een port (dat daarna gewoon aankomt). Verder, als je daarin een kleine bug tegenkomt los je die natuurlijk op (al is het maar alleen in je eigen binary), waarom zou je wachten? Open Source Up Your Ass dus.

Verder lees ik helemaal niets meer dan dat er in de TS staat, en daar staat niets over een APP.

En je opmerking over MSN raakt precies de gevoelige snaar: Als je zo'n client wil laten gebruiken stel je dat toch gewoon in op je jabber server? Jij stuurt jabber xml naar je server, je server stuurt de tekst dan vrolijk door naar jabber clients, icq clients, MSN client en weet ik het waarheen.

Acties:

vrijdag 19 augustus 2005 16:40

GC.Collect(head);

Sendy schreef op vrijdag 19 augustus 2005 @ 16:34:
RobIII >

Nou, je bent een beetje onredelijk. Er is een verschil tussen het programmeren van een protocol met bijpassende client en server en het sturen van wat XML naar een port (dat daarna gewoon aankomt). Verder, als je daarin een kleine bug tegenkomt los je die natuurlijk op (al is het maar alleen in je eigen binary), waarom zou je wachten? Open Source Up Your Ass dus.

Als jij in een klein broadcast protocoll al bugs dondert dan gaat er iets niet goed. Misschien begin je code te kloppen terwijl je al veel vrijdag-bier op hebt, maar zelfs dan heb je dat maandag ochtend in een half uurtje wel weer helemaal recht getrokken en zijn de bugs er uit.

In een paar regeltjes code kun je nooit veel bugs kwijt

En je opmerking over MSN raakt precies de gevoelige snaar: Als je zo'n client wil laten gebruiken stel je dat toch gewoon in op je jabber server? Jij stuurt jabber xml naar je server, je server stuurt de tekst dan vrolijk door naar jabber clients, icq clients, MSN client en weet ik het waarheen.

Dan moet je ze post nog is lezen... waarom wil je trouwens die XML-overhead?

Acties:

vrijdag 19 augustus 2005 17:02

Admin Devschuur®

^ Romeinse Ⅲ ja!

Sendy schreef op vrijdag 19 augustus 2005 @ 16:34:
RobIII >

Nou, je bent een beetje onredelijk. Er is een verschil tussen het programmeren van een protocol met bijpassende client en server en het sturen van wat XML naar een port (dat daarna gewoon aankomt).

En wat is daar zo ingewikkeld aan om zelf te maken? En waarom zou je uberhaupt XML gebruiken?

Sendy schreef op vrijdag 19 augustus 2005 @ 16:34:
Verder, als je daarin een kleine bug tegenkomt los je die natuurlijk op (al is het maar alleen in je eigen binary), waarom zou je wachten? Open Source Up Your Ass dus.

Als je een kleine bug tegen komt mag je eerst door een compleet framework (dat niet van eigen hand is, en waarvan 99% overbodig is omdat je het niet gebruikt) gaan zitten zoeken waar het probleem zit om vervolgens een oplossing ervoor te zien verzinnen. En als je het dan patched ben je een eigen branch aan 't maken en dat is dan bij de volgende "officiële" patch weer een probleem. Je maakt je probleem dus alleen maar erger.

Sendy schreef op vrijdag 19 augustus 2005 @ 16:34:
Verder lees ik helemaal niets meer dan dat er in de TS staat, en daar staat niets over een APP.

Nee, die opmerking wil ik wel intrekken. Zo heb ik het gelezen, maar het staat er idd niet. Waarschijnlijk gedroomd (of ergens in een andere post van TS gelezen)

Sendy schreef op vrijdag 19 augustus 2005 @ 16:34:
En je opmerking over MSN raakt precies de gevoelige snaar: Als je zo'n client wil laten gebruiken stel je dat toch gewoon in op je jabber server? Jij stuurt jabber xml naar je server, je server stuurt de tekst dan vrolijk door naar jabber clients, icq clients, MSN client en weet ik het waarheen.

Ik vind het nog steeds belachelijk dat als ik een very-lightweight protocolletje nodig heb ("SERVER: HEY! Er is iets gebeurd! Bla Bla" -> "CLIENT: Thanks!") om daar een compleet MSN/Jabber/Whatever protocol voor te gaan mishandelen terwijl je 99% van die functionaliteit niet gebruikt. Dat is overhead en zonde van resources (om maar eens iets te noemen, je kunt er vast nog een paar verzinnen). Kijk voor de gein eens in het Botwars topic in P&W (en dan met name het protocol natuurlijk), daar is precies zo'n "lightweight protocol" geïmplementeerd. Waarom zou je dan Jabber/MSN/whatever nodig hebben?

questa schreef op vrijdag 19 augustus 2005 @ 16:39:

Great minds think alike

@Sendy: Niet om te flamen ofzo, maar je beseft dat je in P&W zit he? En dat we hier dus zélf oplossingen schrijven (programmeren) in plaats van kant en klare oplossingen te downloaden en installen.... Daar gaat het hier dus even om. Als dit topic in SA had gestaan had ik je groot gelijk gegeven.

[ Voor 36% gewijzigd door RobIII op 19-08-2005 16:54 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

vrijdag 19 augustus 2005 17:06

Ik schrijf nergens dat het te moeilijk is zelf een protocol te ontwerpen en bijbehorende client en server te schrijven. Ik schrijf alleen dat het makkelijker is om een bestaand iets te gebruiken.

Het niet mijn keuze om XML te gebruiken. Het jabber protocol zit alleen zo in elkaar; als je dat wil gebruiken kan je er niet onheen. En wat is het probleem daarmee?

Waarom denk je trouwens dat het "mishandelen" van het protocol is? Geloof je niet dat jabber/msn/whatever ervoor gebouwd is om boodschappen over te sturen (dus ook status boodschappen van servers bijvoorbeeld)?

En als laatste, ik wens hier niet aangevallen worden omdat jij te lui bent om bugs in Free Software op te lossen. Ik los wel bugs daarin op, en die meld ik dan aan de betreffende programmeur. De volgende release werkt het dan vaak zonder mijn patch. Tevens begon jij te klagen over "open source..."

edit:
Okay, dit was misschien een beetje te stevig gesteld. Mijn excuses.

RobIII schreef op vrijdag 19 augustus 2005 @ 16:40:
@Sendy: Niet om te flamen ofzo, maar je beseft dat je in P&W zit he? En dat we hier dus zélf oplossingen schrijven (programmeren) in plaats van kant en klare oplossingen te downloaden en installen.... Daar gaat het hier dus even om. Als dit topic in SA had gestaan had ik je groot gelijk gegeven.

Ik schrijf toch ook "makkelijk tegen aan te programmeren?" Ik ontken nergens dat er geprogrammeerd moet worden.

[ Voor 37% gewijzigd door Sendy op 19-08-2005 17:36 ]

Acties:

vrijdag 19 augustus 2005 17:12

Admin Devschuur®

^ Romeinse Ⅲ ja!

Point was: Als je een textfile wil wegschrijven, gebruik je dan ook het Word/OpenOffice/Whatever framework?

Sendy schreef op vrijdag 19 augustus 2005 @ 17:02:
En als laatste, ik wens hier niet aangevallen worden omdat jij te lui bent om bugs in Free Software op te lossen

Goed. Ik viel / val je niet aan. Waar doe ik dat dan? Het is gewoon een discussie. Maar als jij dat zo wil voelen prima. Dan bij deze mijn excuses daarvoor. Zullen we dan maar weer ontopic? We hebben denk ik duidelijk gemaakt dat dit teveel overhead mee zou brengen voor zoiets simpels. Als jij daar toch voor zou kiezen: it's a free world. Ik zou het gewoon niet doen en lekker zelf wat bouwen. Maar da's mijn mening maar....

[ Voor 63% gewijzigd door RobIII op 19-08-2005 17:12 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

vrijdag 19 augustus 2005 17:16

GC.Collect(head);

RobIII schreef op vrijdag 19 augustus 2005 @ 16:40:
[...]

Great minds think alike

Daarom ben ik er ook weer op de meeting

Sendy schreef op vrijdag 19 augustus 2005 @ 17:02:
Het niet mijn keuze om XML te gebruiken. Het jabber protocol zit alleen zo in elkaar; als je dat wil gebruiken kan je er niet onheen. En wat is het probleem daarmee?

Overhead, die de TS nou juist niet wil!

Waarom denk je trouwens dat het "mishandelen" van het protocol is? Geloof je niet dat jabber/msn/whatever ervoor gebouwd is om boodschappen over te sturen (dus ook status boodschappen van servers bijvoorbeeld)?

Nee, ze zijn gebouwd voor chat sessies en file transfire en alle troep die erbij komt kijken.

En als laatste, ik wens hier niet aangevallen worden omdat jij te lui bent om bugs in Free Software op te lossen. Ik los wel bugs daarin op, en die meld ik dan aan de betreffende programmeur. De volgende release werkt het dan vaak zonder mijn patch. Tevens begon jij te klagen over "open source..."
[...]

Ik denk dat het implementeren van het Jabber (oid) protocoll nog meer tijd kost dan je eigen protocoll schrijven.

Acties:

vrijdag 19 augustus 2005 17:26

Admin Devschuur®

^ Romeinse Ⅲ ja!

questa schreef op vrijdag 19 augustus 2005 @ 17:12:
Daarom ben ik er ook weer op de meeting

offtopic:
Spamrun gaat vanavond de deur uit

questa schreef op vrijdag 19 augustus 2005 @ 17:12:
Overhead, die de TS nou juist niet wil!

Geen enkele programmeur zou dit moeten willen... Helaas is dat wel steeds meer de tendens. CPU's zijn toch snel genoeg, verbindingen zijn dik zat en HD ruimte zat. Who cares?

questa schreef op vrijdag 19 augustus 2005 @ 17:12:
Nee, ze zijn gebouwd voor chat sessies en file transfire en alle troep die erbij komt kijken.

Precies waar ik op doelde.

questa schreef op vrijdag 19 augustus 2005 @ 17:12:
Ik denk dat het implementeren van het Jabber (oid) protocoll nog meer tijd kost dan je eigen protocoll schrijven.

Eensch is.

[ Voor 45% gewijzigd door RobIII op 19-08-2005 17:17 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

vrijdag 19 augustus 2005 17:31

GC.Collect(head);

RobIII schreef op vrijdag 19 augustus 2005 @ 17:16:
[...]

offtopic:
Spamrun gaat vanavond de deur uit

[...]

Geen enkele programmeur zou dit moeten willen... Helaas is dat wel steeds meer de tendens. CPU's zijn toch snel genoeg, verbindingen zijn dik zat en HD ruimte zat. Who cares?

Helaas wel inderdaad. Je moet niet altijd de makkelijkste weg nemen imho, denk ook aan onderhoudbaarheid. Als voor het Jabber protocoll hebt gekozen en na 3 maanden wil je uitbereiden kan het zijn dat dat niet mogelijk is met jabber, dat zit je alsnog met een probleem en moet je alsnog je eigen protocoll ontwikkelen.

Denk ook vooral aan de toekomst, je eigen protocoll is eigen onderhoudbaarheid, eigen bugfixen, onafhankelijkheid, ge-optimalizeerd dus geen overhead etc.

Naast het punt dat RobIII als gaf zijn dit voor mij ook al wat redenen om niet voor een protocoll te kiezen ala jabber.

offtopic:
DateTime.Now > workEndTime, dus ik ga weekend vieren!

Acties:

Glimi

Designer Drugs

questa schreef op vrijdag 19 augustus 2005 @ 17:26:
Helaas wel inderdaad. Je moet niet altijd de makkelijkste weg nemen imho, denk ook aan onderhoudbaarheid. Als voor het Jabber protocoll hebt gekozen en na 3 maanden wil je uitbereiden kan het zijn dat dat niet mogelijk is met jabber, dat zit je alsnog met een probleem en moet je alsnog je eigen protocoll ontwikkelen.

Denk nou niet een kant op. Als je de Jabber-API gebruikt, zit die functie die je wil hebben bij je uitbreiding er misschien al in. Dat kan dus ook een voordeel zijn.

vrijdag 19 augustus 2005 17:33

Acties:

vrijdag 19 augustus 2005 17:34

GC.Collect(head);

Glimi schreef op vrijdag 19 augustus 2005 @ 17:31:
[...]
Denk nou niet een kant op. Als je de Jabber-API gebruikt, zit die functie die je wil hebben bij je uitbreiding er misschien al in. Dat kan dus ook een voordeel zijn.

Weer meer functies met overhead, weer meer functies van 3e waar weer bugs in kunnen zitten, waar je weer zelf geen controlle over hebt, weer een extra gateway... voelt niet echt lekker aan.

Acties:

vrijdag 19 augustus 2005 17:56

Admin Devschuur®

^ Romeinse Ⅲ ja!

Glimi schreef op vrijdag 19 augustus 2005 @ 17:31:
[...]
Als je de Jabber-API gebruikt, zit die functie die je wil hebben bij je uitbreiding er misschien al in.

En misschien ook niet. En bak je het er dan zelf in? Leuke klus...
Maar ik ben het wel een beetje met je eens. Daarom zal de TS duidelijker moeten zijn, en moeten kunnen anticiperen op mogelijke features die in de toekomst gewenst *kunnen* worden. Maar als we zo gaan redeneren was notepad ook nooit uitgevonden en hadden we allang Word 197 op ons systeem staan.

Wat ik wel even wil benadrukken is dat wij onze mening hier geven op dit forum gebaseerd op een topicstart. En als die niet compleet is, of onduidelijk dan kunnen de antwoorden inderdaad ook onjuist zijn. Maar ik vind dus wel nog steeds, gebaseerd op de topicstart en de posts van de TS, dan questa en ik het bij het rechte eind hebben. Maar hey, wie ben ik? Just my € 0.02 hoor

questa schreef op vrijdag 19 augustus 2005 @ 17:33:
Weer meer functies met overhead, weer meer functies van 3e waar weer bugs in kunnen zitten, waar je weer zelf geen controlle over hebt, weer een extra gateway... voelt niet echt lekker aan.

En dan quote ik mezelf dus even:

RobIII schreef op vrijdag 19 augustus 2005 @ 16:40:
Je maakt je probleem dus alleen maar erger.

Wat questa en ik alleen proberen te zeggen is: Schiet je doel niet voorbij. Waarom allerlei nodeloze dingen in je app opnemen die niet nodig zijn? De footprint (size van de .exe en .dll's etc) wordt groter dan nodig, de gebruikte bandbreedte wordt meer dan nodig (zeker als je XML gaat zitten sturen) en je CPU is cycles aan het wasten aan zooi die nooit gebruikt wordt.

Maar niets of niemand verbiedt de TS om een Jabber protocol te implementeren hoor. Ook ik niet. "Go your geng" zou ik zeggen

edit:

Jammer dat de TS zelf niet meer replyed... Misschien is hij al weekend aan 't vieren en biertjes aan het happen, terwijl wij hier mekaar zitten af te katten

Dan weet ik wel wie het hier beter bekeken heeft

[ Voor 66% gewijzigd door RobIII op 19-08-2005 17:45 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

Infinitive

Je zou ook nog MSN kunnen gebruiken. Er zijn diverse abstracties beschikbaar, bijvoorbeeld:
http://dotnet.org.za/mailowl/archive/2005/04/26/18946.aspx

“dotMSN is a class library to make use of the MSN Messenger Service. The library is built in C# and can therefore be used by all languages the .NET environment supports. DotMSN provides an easy and consistent interface through a clean Object Oriented approach. DotMSN abstracts the low-level MSN protocol so you can quickly integrate dotMSN with your application and make direct use of MSN-connectivity. DotMSN is free and can be used in both non-commercial and commercial applications.”

Met zoiets is het probleem zoals de topic starter voorlegt eenvoudig opgelost, tenzij het af en toe een paar minuutjes down zijn van de messenger service en geen garanties van de library en service voor de toekomst, het niet geschikt maken.

No way dat het schrijven van een eigen protocolletje zonder polling sneller gedaan is dan het gebruik maken van zo'n library.

[ Voor 7% gewijzigd door Infinitive op 19-08-2005 17:59 ]

putStr $ map (x -> chr $ round $ 21/2 * x^3 - 92 * x^2 + 503/2 * x - 105) [1..4]

vrijdag 19 augustus 2005 18:00

Acties:

vrijdag 19 augustus 2005 18:30

Admin Devschuur®

^ Romeinse Ⅲ ja!

Infinitive schreef op vrijdag 19 augustus 2005 @ 17:56:
Je zou ook nog MSN kunnen gebruiken. Er zijn diverse abstracties beschikbaar, bijvoorbeeld:
http://dotnet.org.za/mailowl/archive/2005/04/26/18946.aspx

[...]

Met zoiets is het probleem zoals de topic starter voorlegt eenvoudig opgelost, tenzij het af en toe een paar minuutjes down zijn van de messenger service en geen garanties van de library en service voor de toekomst, het niet geschikt maken.

Met alle respect, maar heb je het topic wel gelezen? MSN is al een stuk of 14 keer genoemd, en er is een hele discussie over MSN/Jabber etc. geweest...

Infinitive schreef op vrijdag 19 augustus 2005 @ 17:56:
No way dat het schrijven van een eigen protocolletje zonder polling sneller gedaan is dan het gebruik maken van zo'n library.

Wanna bet?

Zoals al meerdere keren aangegeven is in dit topic heeft alles zijn voor en nadelen. En het is ook afhankelijk van wat het protocol moet kunnen. Als het alleen maar berichtjes sturen in in de trend van:

code:

1 2	Server->Client: Yo! Dit en dat is er loos Client->Server: Thanks!

..dan is zo'n library nogal overkill he? Wil de TS straks ook filetransfers, webcammen enzovoorts dan is zo'n library inderdaad wel een goede optie. Maar daar vroeg de TS niet om.

[ Voor 56% gewijzigd door RobIII op 19-08-2005 18:07 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

Infinitive

RobIII schreef op vrijdag 19 augustus 2005 @ 18:00:
Met alle respect, maar heb je het topic wel gelezen? MSN is al een stuk of 14 keer genoemd, en er is een hele discussie over MSN/Jabber etc. geweest...

Ik heb alleen maar gelezen over of je nu MSN of Jabber moest nemen, en daarna volgde een discussie over de overheid van het implementeren van het Jabber protocol, compleet met het sturen van XML berichten etc.

In tegenstelling met dat geef ik een link naar een implementatie voor de MSN service. Zo'n library neemt al het gedoe omtrent protocol van je over en heeft dus niet de overhead. De library kan wel veel meer dan dat je nodig hebt, maar dat zie je toch niet. Paar objecten aanmaken, een paar methode aanroepen en klaar.

Een eigen oplossing die moet voldoen aan de eisen van de topic starter is niet zo snel gemaakt. Daar komt ook nog heel wat programmeerwerk bij kijken. Tenzij alle clients een tcp/ip connectie maken met de server en deze altijd open hebben staan. Maar dat wil de TS nou juist niet (om nog onduidelijke reden).

[ Voor 9% gewijzigd door Infinitive op 19-08-2005 18:32 ]

putStr $ map (x -> chr $ round $ 21/2 * x^3 - 92 * x^2 + 503/2 * x - 105) [1..4]

vrijdag 19 augustus 2005 18:54

Acties:

Verwijderd

Topicstarter

Zo, daar ben ik weer, het is heel wat wat jullie getypt hebben, maar ik heb het allemaal weer doorgelezen.

Zoals ik het nu zie is inderdaad een eigen protocol gebaseerd op udp het beste:
client stuurt udp naar udp server (hoeft maar 1 bitje te zijn + userid + udp overhead), de server kijkt of er nieuwe gebeurtenissen zijn, zo ja dan stuurt hij een paar strings terug, zo niet dan stuurt ie een 0 bitje terug.
Al klinkt dat makkelijker dan het is, ik krijg namelijk m'n udp test servertje niet aan de gang, ik vermoed dat m'n nat router voor problemen zorgt en dat ding configureren is een crime. Dus een betere oplossing is zoiets als ik bij het spel trackmania sunrise zag:
als udp het niet doet (door router, firewall, proxy, enz) dan doen we het via tcp. Natuurlijk stateless tcp, want 1000 open tcp connecties is niet normaal.

De client is in principe een windows computer en in de eerste instantie een apart programma. Maar ik zat net naar firefox extensies en xul te kijken en dat is toch allemaal ook erg mooi, voordeel is ook dat de gebruiker niks hoeft te installeren. Maar dat is een ander verhaal.

Ik vind standaard oplossingen ook mooi, maar ik ga niet blindelings voor standaard en kant en klare dingen, pas na een uitvoerige evaluatie van alle andere oplossingen kun je zeggen welke oplossing de beste is in jouw specifieke situatie.

Ik zie nu al bijvoorbeeld een haak aan jabber: ik neem aan dat het niet een soort p2p netwerk is, je moet dus een server hebben, met connecties die constant open zijn (ik neem overigens aan dat jabber tcp gebruikt en niet stateless is). MSN, ICQ en Mirc oplossingen gebruiken de hardware van andere, hoogstwaarschijnlijk krijg ik een ip ban aan m'n bron als ik de hardware te te zwaar belast.

In dit geval zal de bestudering van Jabber/MSN docs langer duren dan het maken van de basic server inclusief een test client. De meeste tijd zal gaan zitten in het een beetje dicht timmeren van de server en gebruiksvriendelijk te maken van de client.

[ Voor 8% gewijzigd door Verwijderd op 19-08-2005 18:56 ]

vrijdag 19 augustus 2005 21:28

Acties:

ATS

Je doet dus eigenlijk nog steeds een poll. Waarom laat je de clients zich niet registreren tegen de server (hoeft maar één keer met een enkel UDP pakketje) en laat je daarna de server een UDP pakketje sturen als het nodig is? Eens in de zoveel tijd een keep-alive pakketje vanaf de client is waarschijnlijk wel handig.
Het hangt er natuurlijk allemaal van af van de hoeveelheid berichtjes die je wil uitwisselen.

My opinions may have changed, but not the fact that I am right. -- Ashleigh Brilliant

maandag 22 augustus 2005 11:40

Acties:

maandag 22 augustus 2005 11:57

GC.Collect(head);

Verwijderd schreef op vrijdag 19 augustus 2005 @ 18:54:
Zo, daar ben ik weer, het is heel wat wat jullie getypt hebben, maar ik heb het allemaal weer doorgelezen.

Zoals ik het nu zie is inderdaad een eigen protocol gebaseerd op udp het beste:
client stuurt udp naar udp server (hoeft maar 1 bitje te zijn + userid + udp overhead), de server kijkt of er nieuwe gebeurtenissen zijn, zo ja dan stuurt hij een paar strings terug, zo niet dan stuurt ie een 0 bitje terug.

Dat klinkt goed, kleine pakketjes en minimale tot geen aanpassingen nodig van de instellingen van router/firewall/etc.

Al klinkt dat makkelijker dan het is, ik krijg namelijk m'n udp test servertje niet aan de gang, ik vermoed dat m'n nat router voor problemen zorgt en dat ding configureren is een crime. Dus een betere oplossing is zoiets als ik bij het spel trackmania sunrise zag:
als udp het niet doet (door router, firewall, proxy, enz) dan doen we het via tcp. Natuurlijk stateless tcp, want 1000 open tcp connecties is niet normaal.

Het is alleen een server probleem, hiermee bedoel ik dat de client pakketjes niet aankomen bij de server omdat bepaalde porten niet geforward zijn waardoor de server niet berijkbaar is. Client side hoeft er waarschijnlijk niets ingesteld te worden in de router/firewall/etc.

MSN, ICQ en Mirc oplossingen gebruiken de hardware van andere, hoogstwaarschijnlijk krijg ik een ip ban aan m'n bron als ik de hardware te te zwaar belast.

Leuk als dan ander ziet dat je hun server misbruikt en de stekker er uit trekt.

In dit geval zal de bestudering van Jabber/MSN docs langer duren dan het maken van de basic server inclusief een test client. De meeste tijd zal gaan zitten in het een beetje dicht timmeren van de server en gebruiksvriendelijk te maken van de client.

Eensch.

ATS schreef op vrijdag 19 augustus 2005 @ 21:28:
Je doet dus eigenlijk nog steeds een poll. Waarom laat je de clients zich niet registreren tegen de server (hoeft maar één keer met een enkel UDP pakketje) en laat je daarna de server een UDP pakketje sturen als het nodig is? Eens in de zoveel tijd een keep-alive pakketje vanaf de client is waarschijnlijk wel handig.
Het hangt er natuurlijk allemaal van af van de hoeveelheid berichtjes die je wil uitwisselen.

Omdat de TS niet constant een connection wil hebben. Het pollen is niet erg, met de hardware van tegenwoordig en de huidige snelheden van het internet moet 1000 clienten die pollen geen problemen opleveren.

Acties:

maandag 22 augustus 2005 12:05

Verwijderd schreef op vrijdag 19 augustus 2005 @ 18:54:

Zoals ik het nu zie is inderdaad een eigen protocol gebaseerd op udp het beste:
client stuurt udp naar udp server (hoeft maar 1 bitje te zijn + userid + udp overhead), de server kijkt of er nieuwe gebeurtenissen zijn, zo ja dan stuurt hij een paar strings terug, zo niet dan stuurt ie een 0 bitje terug.

En hoe weet de server of er een nieuwe gebeurtenis is? Daarvoor moet de server weten wat de laatste gebeurtenis is die de client heeft ontvangen. Dat vereist of een bevestiging van de client bij ontvangst en het bijhouden van state info op de server, of dat vereist dat de client het ID van het laatste bericht meestuurt. (Werken met timestamps kan ik je niet aanraden tenzij je zeker weet dat iedereen NTP draait.)

Acties:

ATS

questa schreef op maandag 22 augustus 2005 @ 11:40:
Omdat de TS niet constant een connection wil hebben. Het pollen is niet erg, met de hardware van tegenwoordig en de huidige snelheden van het internet moet 1000 clienten die pollen geen problemen opleveren.

Sinds wanneer heb je voor UDP een connectie nodig?

My opinions may have changed, but not the fact that I am right. -- Ashleigh Brilliant

maandag 22 augustus 2005 12:07

Acties:

Tomatoman

Fulltime prutser

Ik blijf pollen toch maar een rare oplossing vinden. Bij pollen loop je per definitie op een bepaald moment tegen schaalproblemen aan. Ik zou daarom voor een connectionless protocol gaan, bijvoorbeeld UDP. Daarover stuur je alleen wat statusmessages heen en weer.

Client messages:
• Abonnering: client meldt dat hij berichten wil ontvangen als die er zijn
• Stay-alive message: client meldt iedere x minuten (60 of zo) dat hij nog steeds geïnteresseerd is in berichten
• Stuur me nu bericht XYZ
• Einde abonnering: client hoeft geen berichten meer, bijvoorbeeld omdat hij offline gaat

Server messages:
• De server heeft bericht XYZ klaarstaan
• Het daadwerkelijke bericht XYZ (of een URL waar deze op te halen is)

Iedere client abonneert zich en stuurt zo nu en dan een stay-alive message. Als de server lange tijd geen stay-alive message heeft ontvangen, gaat hij ervan uit de de client pleite is, wat gelijk is aan einde abonnering. Zodra de server een nieuw bericht heeft, stuurt hij alle geabonneerde clients een message dat bericht XYZ klaarstaat. Het bericht zelf wordt niet verzonden, dat scheelt een hoop verkeer naar clients die intussen niet meer bereikbaar zijn. Alle clients die op dit bericht reageren, krijgen het bericht daadwerkelijk afgeleverd.

Wat voor communicatieprotocol je ook kiest, een dergelijk messagesysteem is goed schaalbaar en beperkt netwerkverkeer tot een minimum. Het is in ieder geval efficiënter dan polling en zorgt dat clients berichten met een minimale vertraging ontvangen.

Een goede grap mag vrienden kosten.

maandag 22 augustus 2005 12:17

Acties:

maandag 22 augustus 2005 12:28

tomatoman schreef op maandag 22 augustus 2005 @ 12:07:
Ik zou daarom voor een connectionless protocol gaan, bijvoorbeeld UDP. Daarover stuur je alleen wat statusmessages heen en weer.

Client messages:
• Abonnering: client meldt dat hij berichten wil ontvangen als die er zijn
• Stay-alive message: client meldt iedere x minuten (60 of zo) dat hij nog steeds geïnteresseerd is in berichten
• Stuur me nu bericht XYZ
• Einde abonnering: client hoeft geen berichten meer, bijvoorbeeld omdat hij offline gaat

Server messages:
• De server heeft bericht XYZ klaarstaan
• Het daadwerkelijke bericht XYZ (of een URL waar deze op te halen is)

Iedere client abonneert zich en stuurt zo nu en dan een stay-alive message. Als de server lange tijd geen stay-alive message heeft ontvangen, gaat hij ervan uit de de client pleite is, wat gelijk is aan einde abonnering.

UDP heeft uit zichzelf geen guaranteed delivery.Dus als stay alive berichten kwijt raken dan denkt de client dat hij nog geabonneerd is terwijl de server denkt dat de client pleite is.

Als je serieus gebruik wil maken van UDP dan moet je naar een Group Communication systeem kijken met guaranteed delivery.

Acties:

maandag 22 augustus 2005 12:40

GC.Collect(head);

ATS schreef op maandag 22 augustus 2005 @ 12:05:
[...]

Sinds wanneer heb je voor UDP een connectie nodig?

* pjvandesande leest niet best op maandag-ochtend blijkt wel weer

Acties: