DBFastClock

[AndersB]

Johan testade nyss med MRclock som server och DBfastclock som klient.
Försökte några gånger med omstart etc. och var på väg att ge upp. Sen funkade plötsligt.
Nu har jag testat från min dator och då funkade det direkt.

En annan skillnad mellan hur den jobbar mot servrarna.
När man stoppar MRclockserver så visar DBfastclock streck tills man dragit igång servern igen då allt fortsätter att fungera igen.
Med MRclock som server så återupptas inte kommunikationen efter serveromstart, utan man får starta om DBfastclock för att få tiden igen.

mvh/anders

[MarcusHorn]

Jag testade lite till, och får detta i terminalen när jag startat DBFastClock och har MRClock i telefonen som master:

Kod: Markera allt

macmarcus:DBFastClock_bin marcus$ java -jar DBFastClock.jar 
Exception in thread "Thread-3" java.lang.StringIndexOutOfBoundsException: String index out of range: 10
	at java.lang.String.substring(String.java:1934)
	at dbfastclock.TCPClientComm.run(TCPClientComm.java:71)
	at java.lang.Thread.run(Thread.java:680)
macmarcus:DBFastClock_bin marcus$ 

Vilken sträng som blir för lång vet jag inte, men antalet tecken (10) får mig att tro på den första delen av serversvaret, alltså tidsdelen.

/Marcus

[daniel]

Tackar!

Det intressanta i utskriften ovan är raden:
at dbfastclock.TCPClientComm.run(TCPClientComm.java:71)

Vilket säger att felet uppkommer när programmet försöker tolka parametern "Speed", dvs hastigheten som klockan har. I Lars klocka var den två tecken, dvs mellanslag+siffra eller två siffror. Om jag tolkar telnet-utskriften rätt så har MRclock bara en siffra. Det stämmer också bra med felmeddelandet "String index out of range: 10". I Lars klocka, som är "orginalet" som bestämde version 1 av protokollet, så är formatet "a hh mm ff" där:
a = 1 om klockan är aktiv, annars 0
hh = timmar (två tecken). 0 - 59
mm = minuter (två tecken). 0 - 59
ff = fart (hastighet) på klockan (två tecken). 0 - 59

Hela strängen som Lars klocka skickar ut är alltså 10 tecken lång och DBFastClock förväntar sig alltså det.

Mvh Daniel

[daniel]

@Marcus: Prova gärna att ställa MRclock på hastighet 10 eller högre. Då bör DBFastClock fungera normalt eftersom hastigheten då behöver anges med två siffror.

Mvh Daniel

[AndersB]

Japp, funkar med hastighet 10+ men inte lägre.
Dina tidigare program har klarat lägre hastigheter!?!
mvh/anders

[daniel]

DBFastClock är delvis ny kod, bl a pga av nya protokollet. Min förra klient, FastClockSimpleClient, brydde sig inte om hastigheten alls, så för den spelade felet ingen roll. Det kanske är så att DBFastClock inte har provats med MRclock som server tidigare?

Mvh Daniel

[MarcusHorn]

Se där, så ska det se ut! Tack Daniel! Och det förklarar varför det funkar mot mitt lilla fulhack också, jag satte hastigheten till 10 av ren slump... Men en liten felhantering kanske är på plats så DBFastClock kan hämta sig från en nätverksglitch eller motsvarande.

[daniel]

Felhantering???? Vad är det???

Skämt åsido, programmet ska inte krascha så jag får fixa det.

Mvh Daniel

[daniel]

Jag hade fel om protokollet och problemet ligger i DBFastClock och inte i MRclock. Jag har nu ändrat DBFastClock så att det ska klara av protokollet korrekt.

Bifogad fil innehåller enbart jar-filen, inte resten av filerna som behövs, så packa upp filen och lägg jar-filen i samma bibliotek som resten. Eftersom jag inte har en android-telefon så har jag inte kunnat testa mot MRclock men jag hoppas denna version funkar bättre.

Mvh Daniel

[LLJ]

Utan att ha kollat på någon källkod så tror jag att problemet har varit att "mellanslag" använts som fältavskiljare och kommer det då dubbla "mellanslag" så missar man helt enkelt ett fält.
Så var min ursprungliga god uppbyggd om jag minns rätt, dvs längden var inte fast.

/Lars