Android - servern svarar inte...

[clabos]

Hej
Jag försöker få igång Android-klienten mot min SwitchKing-server. Först lite bakgrund...
Min server ligger på en virtuell XP, SP3. Jag har fått igång webbtillägget så att jag via webbläsaren kan slå av/på mina devices. Jag var tvungen att byta port för att få klienten att funka, dvs jag ändrade i SwitchKing Service Host exe.config till:
<baseAddresses>
<add baseAddress="http://localhost:8081/SwitchKingFrameworkServiceHost"/>
</baseAddresses>

Min android funkar klockrent mot er testmiljö men inte mot min egen server. Jag har följt felsökningsartikeln på er sajt men inte lyckats lösa problemet. Jag har uppdaterat både klient och server till senaste version, servern är i version 0.9.0.32, db 1.82.

När jag försöker ansluta via wifi från min telefon får jag inget felmeddelande oavsett vad jag anger för ip/port/user/pw, det verkar helt enkelt inte som om telefonen når fram. Jag kör inte windowsbrandvägg på servern. Tänkte att det kanske är någon kollision på port 8800 så jag har testat att byta. Jag ändrade till:
<!-- REST Service config -->
<service name="SwitchKing.Server.RESTServices.RESTData" behaviorConfiguration="RESTBehavior">
<endpoint bindingConfiguration="RESTHttpSecure" address="http://localhost:8910" binding="webHttpBinding" contract="SwitchKing.Common.Contracts.REST.IRESTService" />
</service>

...men det hjälpte inte. Det funkar inte heller när jag försöker ansluta vi en lokal webbläsare (http://localhost:8910/devices [eller 192.168.0.93 eller 127.0.0.1]). Jag startade om invoke- och REST-servicarna innan jag testade förstås. Testade netstat -ba, här är ett urklipp:
TCP ClaesSuperdator:8081 ClaesSuperdator.mindomän.se:0 LISTENING 5064 [SwitchKing Service Host.exe]
TCP ClaesSuperdator:8800 ClaesSuperdator.mindomän.se:0 LISTENING 5064 [SwitchKing Service Host.exe]
TCP ClaesSuperdator:4480 localhost:8081 ESTABLISHED 1760 [SwitchKingPro.exe]
TCP ClaesSuperdator:8081 localhost:4480 ESTABLISHED 5064 [SwitchKing Service Host.exe]

Dvs jag hittar inte något spår efter att något lyssnar på 8910. Då undrar jag om min config är rätt...

Jag har bifogat min konfig men här är stycket jag är fundersam kring (edit: kan inte ladda upp, får fel på sajten som säger att filtypen inte är tillåten [oavsett .config/.txt/blank]):
<services>
<!-- Framework Service Config -->
<service name="SwitchKing.Server.WCFServices.FrameworkData" behaviorConfiguration="metadataSupport">
<host>
<baseAddresses>
<add baseAddress="http://localhost:8081/SwitchKingFrameworkServiceHost"/>
</baseAddresses>
</host>
<endpoint address="" binding="wsHttpBinding" bindingConfiguration="NoSecurity" contract="SwitchKing.Common.Contracts.IFrameworkService"/>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
<!-- REST Service config -->
<service name="SwitchKing.Server.RESTServices.RESTData" behaviorConfiguration="RESTBehavior">
<endpoint bindingConfiguration="RESTHttpSecure" address="http://localhost:8910" binding="webHttpBinding" contract="SwitchKing.Common.Contracts.REST.IRESTService" />
</service>
</services>

Efter denna långa utläggning kommer så mina frågor...
1) Finns det något samband mellan baseAddress (som jag ändrat till 8081) och REST-servicen, eller funkar REST oavsett baseAddress?
2) Varför ser jag inte något spår av att port 8910 är använd i min netstat trots att jag startat om alla SWK-servicar samt IIS? Ändrar jag på fel ställe?

Alla tips är välkomna!
/Claes

[Martin]

Först skulle jag rekommendera att köra följande istället:

Code: Select all

netstat -an |find /i "listening"

...Switch Kings portar syns på min burk som på skärmbilden nedan. Om porten syns där så är garanterat tjänsten uppe och snurrar...

NETSTAT.png

Code: Select all

<endpoint bindingConfiguration="RESTHttpSecure" address="http://localhost:8910" binding="webHttpBinding" contract="SwitchKing.Common.Contracts.REST.IRESTService" />

Detta ser helt rätt ut. Du bör ha port 8910 på "netstat-listan" ovan...

Generellt är det så att om konfigurationsfilen är felaktig så stoppar tjänsten direkt. Bra att veta är att en ändring av port kräver omstart av alla tjänster.
Den första tjänsten som startar läser in konfigurationsfilen vid start och därefter läses den inte om vid förändring.

Om REST-tjänsten inte kan öppna upp sin kanal så bör du se detta antingen i Switch Kings egen loggfil eller i Windows loggbok. Har du tittat där? Sök efter "Warning", "Error" eller "Fatal".
(det kommer att finnas ett felmeddelande för varje gång du stoppar och startar tjänsten - detta är normalt)

Du kan också titta efter följande i Switch Kings loggfil:

Code: Select all

Opening service channel for REST.

och

Code: Select all

Service channel for REST opened.

Om bara första meddelandet syns men inte det andra så har Switch King uppenbarligen inte lyckats starta tjänsten, men har försökt.
Om det andra meddelandet syns så är tjänsten igång och då bör det vara något annat som spärrar...

[Martin]

...har lagt till så att det är möjligt att skicka upp lite fler typer av filer...

[clabos]

Tack för hjälpen, nu funkar det. Kan inte säkert säga varför men jag hade lite problem med att få rätt port att "bita". Tar på mig skulden
/Claes

[redina]

Jag hade också problem med att få windows egna brandvägg att fatta att jag hade öppnat den. Men efter ett tag tyckte den att det var okay. Vet inte varför. Så en lösning på REST-problemen är att fixa allt och sen vänta några timmar och sen testa

[ekis]

Jag hade också problem med att få windows egna brandvägg att fatta att jag hade öppnat den. Men efter ett tag tyckte den att det var okay. Vet inte varför. Så en lösning på REST-problemen är att fixa allt och sen vänta några timmar och sen testa

Om man startar om tjänsten så skall ändringarna slå direkt. Blir lite tidskrävande om man skall vänta ett par timmar för varje ändring man gör, om man nu testar lite olika portar alltså.

[Martin]

Blir lite tidskrävande om man skall vänta ett par timmar för varje ändring man gör, om man nu testar lite olika portar alltså.

Håller med. Jag har ingen erfarenhet av detta, men så byter jag inte portar så ofta och använder dessutom inte Windows-brandväggen...

Den första tjänsten som startar läser in konfigurationsfilen vid start och därefter läses den inte om vid förändring.

Risken är nog störst att Framework-tjänsten är igång och att man bara startar om REST-tjänsten, vilket inte duger eftersom filen inte läses om...