Gå til innhold

utvikling av server/klient keepalive applikasjon


Anbefalte innlegg

TCP Keepalive?

 

Jeg har en applikasjon som tilbyr i overkant av 20 brukere uregelmessige oppdateringer.

Applikasjonen er bygd opp med innlogging som sjekkes hvert femte minutt ved at den forespør login credentials fra brukeren. Dette virker som en verifisering av klienten som forespør oppdateringene. Videre så sendes det forespørsler fra hver bruker ca hvert 10'ende sekund mot applikasjonen. Som forsåvidt bør være nok "keepalive"?

 

I den senere tid så har det imidlertid oppstått problemer med ustabilitet som fører til at brukere faller av og mister oppdateringer. Dette er uheldig da klientsoftwaren hos brukerene ikke automatisk kobler seg på igjen, noe som krever omstart initiert av brukeren.

 

Jeg har også mistanker om at min internettforbindelse delvis kan ha skyld i dette. Da det i den senere tid oppleves korte brudd, 1-3 sekunder, hvor all trafikk disconnecter. Spesiellt en lav QoS (nedi 20% basert på hastighetsmåler hos ISP) og høye forsinkelser på pakkene. Dette linjeproblemet jobber ISP'en med å finne ut av.

 

dessverre så oppleves brudd mellom klient og server oftere enn brudd på linjen.

 

Jeg har ikke noen kontroll med hverken applikasjonen eller klientsoftwaren. Så jeg ønsker å bygge en server/klient applikasjon for å verifisere linjekvaliteten, ev. om det er tcp stack'en som bidrar til feil.

 

Server applikasjonen må kunne ha en config del med følgende parameter :

Portnummer som skal åpnes for trafikk. (gjerne flere porter samtidig)

Brukernavn

Passord

Intervall, i sekunder for hvor ofte klienten skal forespørres om å re-autentifisere seg.

Innhold, i datapakke som sendes til mottaker (128Bytes ascii string)

Path, til logfil

 

Klient applikasjonen må kunne angi følgende parameter :

Servernavn, domenenavn eller ip adresse

Portnummer, eventuellt flere

Brukernavn

Passord

Interfall, i sekunder for hvor ofte den skal forespørre datapakken

Path, til filen den inkrementellt skal lagre datapakkene i

 

Formatet på logfilen til server tenkes utformet slik :

Datotid, dd.mm.yy - hh:mm:ss

Auth, bruker innlogget eller avvist, med info om årsak til hvorfor ikke (feil bruker/passord eller timout på tcp keepalive?)

Datapakke forespurt

Datapakke bekreftet mottatt av klient

Spacer (for lettere lesbarhet av log'en)

 

Formatet på logfilen til klienten tenkes utformet slik :

Datotid, dd.mm.yy - hh:mm:ss

Auth, sjekket om man fortsatt er auth av server (om ikke bør applikasjonen sende auto-login)

Datapakke forespurt

Datapakke verifisert

Datapakke bekreftet til server

Datapakke bekreftet av server

 

Meningen med dette er å få sjekket hvorvidt en slik tjeneste kan stå å gå feilfritt over en lengre periode. Kravet er 100% oppetid. Dersom datapakke forespørres men ikke mottas skal den forespørres automatisk på nytt til den mottas, så fremt klienten er pålogget. Dersom klienten ikke er pålogget skal det automatisk sendes login info til server - og loggføres at forbindelsen har vert brutt.

 

Forslag til log av denne event : (3delt)

Datotid, dd.mm.yy - hh:mm:ss

Datapakke ikke mottat, forespørsel resent (repeteres til den er mottatt, og logges som mottat som beskrevet i de neste 2 linjene)

 

Datotid, dd.mm.yy - hh:mm:ss

Datapakke mottat, forespørsel repetert X ganger (vel, hvor mange ganger den er forespurt kan jeg gidde å telle manuellt i logfilen)

 

Datotid, dd.mm.yy - hh:mm:ss

Keepalive missed, auth resent

Datapakke forespurt

Datapakke verifisert

Datapakke bekreftet til server

Datapakke bekreftet av server

 

--

Plattform dette kjøres på pr. i dag er GNU/Linux 2.6.16.9 Slackware.

 

Nå har jeg minimalt med erfaring i å programmere i linux. Så jeg har ingen formening om hvor mye arbeid som ligger i et sånnt prosjekt. Dette er det første jeg trenger svar på. (arbeidsmengde en kan forvente noe sånnt tar)

Deretter så ser jeg så klart etter noen som kanskje har dette i fingertuppene og kan sende meg avgårde i rett retning. Valg av språk å kode i er ikke så farlig for min del, jeg er i stand til å lære det jeg må for å kunne gjennomføre dette.

 

Det finnes sikkert andre måter å gjøre dette på, eller ting jeg ikke har tenkt på som kanskje bør være med. Så jeg er åpen for alle forslag for forbedringer eller endre spesifikasjonene for å bedre overvåke kvaliteten på "oppetiden" i en sånn tjeneste.

 

Linker til ressurser for å gjøre dette på egenhånd settes også pris på (bøker, forum, tutorials og annen dokumentasjon)

 

Spørsmål svarer jeg så klart på om noe over her ikke gir mening i det heletatt.

 

Alle innspill mottas med stor takk.

Lenke til kommentar
Videoannonse
Annonse

Det skulle faktisk ikke ta så lang tid å lage dette, når det kommer til socketprogrammering under unix/linux anbefaler jeg denne guiden her: http://www.beej.us/guide/bgnet/

Det kan fint la seg gjøre på en kveld dette programmet, men da blir det uten GUI. Vil du ha gui kan du ligge til noen timer, men what-the-heck. GUI trengs da ikke?!

 

Også når vi første er i gang så ville jeg stukket snuten innom Programvare -> GNU/Linux delen av forumet og hørt i stickyen "den frie kafeen", om noen ikke har vært bort i eksisterende programvare før du går igang med utviklingen.

Lenke til kommentar

Takk for svar, skal sjekke dette.

Godt å høre at dette ikke er et evighetsprosjekt men relativt fort gjort.

Da skal det nok være overkommelig selv med min erfaring. Læreviljen er stor nok hehe.

GUI trengs ikke nei og log'ing kan skje til standard loggfiler i linux og ikke mot egne logg filer om det gjør det enklere f.eks.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...