Problem med bibehållandet av statuset "inloggad"

[Thaisambo]

Hej, jag sitter nu på ett studenthotell i Bangkok och har en hel del problem med att bibehålla statuset “inloggad”.

Vad som händer är att jag av någon anledning – periodvis mycket frekvent – tappar den identifierande informationen under dialogen med servern vilket ställer till med problem vid försök att skriva inlägg, posta dessa och ev redigera. Ibland får jag repetera inloggningsförsöken en massa gånger innan jag kommer in och även då är det instabilt. Beteendet är oregelbundet och jag tror inte det beror på någon programuppdatering av forumet.

Exakt hur Thailandsforum bibehåller status för sessionen vet jag inte i detalj, men eftersom den ska vara stabil tills antingen logout eller inactivity timeout inträffar så borde det vara en cookie eller möjligen SID parametern om det nu står för “Session ID”. Eller någon annan variant av HTTP parameter – jag har ingen sniffer tillgänglig och kan inte spela in eller kika på paketutväxlingen.

Problemet kommer sannolikt från något hos nätoperatören, den som står för det lokala spridningsnätet som är trådlöst, ett privat lokalnät. Jag vet inget om det, det kan vara ett lokalt filter som (ojämnt!) filtrerar HTTP headers.

Men tekniken för hantering av olika inloggade användare på forumet borde vara resistent mot sånt och det är den inte – dock har jag aldrig haft det här besväret förrän nu på just denna anslutning. Jag kommer inte att kunna reproducera det här när vi kommit hem till Sverige igen om två veckor.

Vet inte om någon annan råkat ut för samma typ av problem heller.

Säg till om vi ska göra något annars tar jag det som det är nu och fortsätter så gott det går tills vi kommer hem och slipper det här.

[gosatta]

ja låter ologiskt så en ren gissning är att deras lokala nätverk är tokigt uppsatt så den byter IP på interna uppkopplingar hipp som happ..

[Thaisambo]

Det är inte något byte av intern IP adress, möjligen skulle det vara extern, publik adress, men det tror jag inte. Det skulle störa trafiken något enormt i och med att en ny DHCP dialogsession måste köras för att få en ny IP adress. Skadade eller filtrerade HTTP headers kan det vara, men jag ser inte det beteendet på någon annan applikation.

Men jag vet inte hur detta är löst i Thailandsforum, vet man det underlättar det diagnosen och felsökningen betydligt. Skulle nog kunna klura ut det ändå, men har ju ingen sniffer tillgänglig! Annars är det en bra anslutning för thailändska förhållanden, får ut 5 Mbps nedströms och 512 Kbps uppströms, de använder någon form av lastbalansering för att styra bandbredden till sina lokala kunder så det är inte en helt okvalificerad anslutning. Tror det är Bangkok University eller något liknande som äger anläggningen. Men något är fel och det gäller enbart Thailandsforum applikationen.

[Thaisambo]

Jag fick det problemet en massagånger nu när jag skulle försöka läsa den här tråden, som ju är skyddad. Lyckades till slut läsa Seaserpents och Skalmans inlägg – ok, fler än jag har liknande problem. Det får forumets teknikgrupp kika på.

[Thaisambo]

Det tror jag inte, sessionerna från Thailandsforum resp den här servern på jobbet går på olika lokala TCP portar (jag antar att det är samma protokoll, HTTP) och ska inte kunna störa varandra. I så fall är det fel i WINSOCK plattformen (ett sätt att implementera TCP/IP som ursprungligen kommer från arkitekturen bakom Berkeley Socket på Unix).

Nej det är något som orsakar att dataöverföringen inte är resistent vare sig det gäller HTTP headers eller HTTP data. Jag vet inte var informationen om vem som är den inloggade partnern för servern finns lagrad för transport eller hur den är designad. Men detta ska forumets teknikgrupp känna till, något är inte som det ska här pga den konstadetade svaga resistansen, kanske fel längd på någon buffert nånstans. Dock underligt att det varierar med vilken internetanslutning som används. De kritiska är kanske såna som går genom någon typ av proxy eller paketfilter.

[Nille]

Jag upplever också forumet som mer hackigt än vanligt just nu. Skall se vad vi kan göra för att åtgärda detta.

[Thaisambo]

Jag är lite konfunderad över switchen “Logga in automatiskt”, den är normalt avmarkerad hos mig och jag har nog använt den tidigare för rätt länge sen. Möjligtvis hette den något i stil med “Håll mig inloggad” eller liknande.

Om jag använder den nu så blir problemet mer transparent, det märks inte lika mycket, och som slutanvändare uppfattar man naturligtvis det som att “det fungerar”. Då har jag inte kollat hur paketutväxlingen bakom på linjen blir, om det är samma beteende – men “osynligt” – så innebär det ju en massa paket fram och tillbaka innan inloggningen “biter”. I så fall är inte grundproblemet bakom löst helt enkelt utan bara “dolt” för slutanvändaren, man har gjort en “workaround” och en liktig lösning borde tas fram om det nu finns tid och pengar till det, men det kräver också att man kan hitta och diagnosticera felet.

Det finns någon sorts gräns på hur många gånger försök att “Logga in automatiskt” görs – självklart eftersom man annars kan hamna i en oändlig loop med “bouncing packets” – för ibland kan jag ändå hamna i statuset “ej inloggad”. Då har den gett upp förstås och jag får ta hand om det manuellt.

Hoppas det går bra att få rätsida på detta – vad det har med att jag sitter på Bangkoks Universitets studentnät nu att göra vet jag inte och detta problem har jag inte haft vare sig hemma, via 2G/3G eller någon annanstans. Det är något speciellt i användarens lokalnät, kanske i gatewayn till Internet, som inte klarar av transporten bra. Något paketfilter eller en möjlig proxy an något slag – och då kan man ju inte reproducera det utan vidare varsomhelst.

[Author]

Posts