fixed IP's in Android apps

[kinderpindakaas]

Ik heb het volgende probleem.
Als beginnende Android developer ben ik bezig met een app te ontwikkelen die moet communiceren met andere gsm's die ook deze app draaien.

Hoe pak ik dit aan?
Aangezien een communicatie random IP <-> random IP knap lastig is.
Een alternatief is om een soort gameserver er tussen te zetten met een bekend IP adres:
randomIP <-> fixed IP gameserver <-> random IP

Op die manier kan ik dan alle apps die draaien zich eerst laten aanmelden bij de gameserver, zodat ik hun IP adres weet en kan ik daarna een netwerk maken.
Maar het nadeel is dan dat je bijvoorbeeld je ip adres van je gameserver niet meer kan wijzigen.

Zijn er in de praktijk peer-to-peer oplossingen bekend waarbij er geen gameserver nodig is?

[bvdbijl]

Je kan ook een domein gebruiken ipv een fixed IP van de gameserver, dan kan je die op elk moment wijzigen
Maar volgens mij is het erg moeilijk/onmogelijk om een peer-to-peer oplossing te maken zonder tracker (net zoals bittorrent)

[Jaap-Jan]

In plaats van een IP- adres zou ik een domeinnaam gebruiken. Op die manier kun je van server verhuizen zonder je programma's aan te hoeven passen. Een andere optie is het configurabel maken.

Als je voor een ad-hoc oplossing (zonder centrale server) wilt gaan, zou je ook kunnen kijken naar Zeroconf.

[NMe]

Ook bij peer to peer heb je voor het gemak een server nodig die broker speelt en de juiste verbindingen legt. Sowieso maak je geen verbinding met IP's maar heb je je server netjes op een hostnaam beschikbaar. Die blijft gewoon hetzelfde zolang je voor je domein betaalt.

[voodooless]

kinderpindakaas schreef op dinsdag 19 oktober 2010 @ 14:55:
Zijn er in de praktijk peer-to-peer oplossingen bekend waarbij er geen gameserver nodig is?

Nee. De rede daarvoor is ook heel simpel: peer to peer werkt op mobile netwerken in de meeste gevallen helemaal niet. De meeste providers delen helemaal geen publieke IP adressen uit, en zodoende zitten dus alle mobieltjes achter een NAT netwerk. Kans is zelfs groot dat dat binnen een provider niet goed gaat als ze meerdere pools en gateways gebruiken.

Kortom: niet doen dus!

Zorg gewoon dat je applicatie een lijstje heeft van domeinnamen waar je terecht kunt voor je "gameservers" eventueel kun je dat lijst van afstand updatebaar maken (al is een DNS aanpassing vaak eenvoudiger en betrouwbaarder).

[kinderpindakaas]

Ok, gewoon gebruik maken van een domeinnaam die ik in het ergste geval in de app kan wijzigen mocht ik een ander domein willen gebruiken.
Wat ik wel wil voorkomen is dat mijn app moet gaan "pollen" bij de gameserver wat de status van andere cliënts zijn.

Dus als mobiel A op een button tikt, dat mobiel B niet steeds in een loop moet gaan opvragen aan de gameserver of mobiel A een button heeft ingetoetst.
Is het mogelijk dat ik de gameserver een commando naar mobiel B stuur zodra mobiel A op een knop drukt?
Of is een simpele duplex socket openen iets te simpel gedacht?

[michiel_]

Wat is er mis met:
Client A -> server: Ik spring!
server -> client b: Client A springt!

[Janoz]

Twee dingen:

1 - We hebben het neem ik aan over een socket verbinding, en geen verkapte webservices. Een socket werkt gewoon twee kanten op. Wat je er aan de ene kant in schrijft is aan de andere kant weer uit te lezen.
2 - Je hoeft de server niet altijd te gebruiken. De server weet de IP's van beide spelers en kan aan de spelers elkaars IP doorgeven waardoor ze rechtstreeks kunnen verbinden.

Punt 2 is trouwens tegenwoordig wat lastiger haalbaar. Steeds meer mensen gaan via NAT online, en dan gaat dat niet op en zul je dus sowieso een server als proxy moeten gebruiken.

[NMe]

Kijk ook eens naar het distributed observer pattern. Ik heb zelf weinig tot geen ervaring met distributed software maar ik herinner me uit mijn schooltijd dat je daarmee zonder continu te lopen pollen informatie kan delen tussen server en client.

[kinderpindakaas]

Het zou best eens kunnen zijn dat het wel een soort van verkapte vorm van webservice moet worden.
Want als je de boel 24 online wilt hebben, moet je al snel aan een webhosting denken.
Of ik moet een hosting vinden waarmee ik ook andere vormen van services kan draaien.

[voodooless]

Wat heeft 24/7 met webhosting te maken Er zijn genoeg bedrijven die je gewoon een virtuele server aanbieden waar je op mag doen wat je wil (binnen grenzen natuurlijk).

Al heeft een verkapte webservice omgeving ook voordelen. Je kunt het makkelijk deployen op veel plekken, en je hebt het minste last van firewall issues.

Met long-polling kun je al heel aardig maken wat jij wil denk ik.

[kinderpindakaas]

Zolang apps hun IP adres gewoon naar een php page posten, dan kan ik in een webserver natuurlijk wel een game runnen. Maar dan moeten apps enkel ff om de 10 seconden even een update opvragen.
In het geval van deze app moet dat wel te doen zijn.
Een 10 seconden delay is acceptabel, maar het zal niet de mooiste oplossing zijn vrees ik

[Janoz]

Als je toch enkel via de server speelt is er helemaal geen noodzaak om de ip's te posten.

Maar een webserver is maar een van de vele mogelijke server implementaties die er bestaan.

[Caelorum]

Ik zou zelf eerder voor een masterserver gaan.
Clients kunnen daar naartoe verbinden om een lijst met games en/of andere beschikbare clients te verkrijgen.
Vervolgens kan er via die server contact met elkaar worden gelegd, waarna beide clients onderling verder gaan zonder de masterserver.
Vooral dit laatste zal de reactiesnelheid wel wat verhogen, als dat belangrijk is.

[ Voor 12% gewijzigd door Caelorum op 21-10-2010 11:24 ]

[Woy]

Caelorum schreef op donderdag 21 oktober 2010 @ 11:23:
Vervolgens kan er via die server contact met elkaar worden gelegd, waarna beide clients onderling verder gaan zonder de masterserver.

Maar zoals gezegd, kan dat tegenwoordig nogal wat problemen opleveren op mobiele netwerken, en ook bij gewone clients met NAT

[Janoz]

Sterker nog, ik denk dat devices die via wifi verbinden per definitie achter een router zitten en dus geen extern IP hebben.

Gewoon de server als proxy gebruiken. Het verlies in snelheid is te verwaarlozen. Pas als dat goed werkend is kun je van daaruit proberen andere mogelijkheden op te zetten (wanneer 2 devices vanaf hetzelfde externe IP komen zou je ze elkaar hun interne ip kunnen geven om zo te proberen via het lokale netwerk te verbinden bijvoorbeeld)

[ThaNOD]

Janoz schreef op donderdag 21 oktober 2010 @ 11:55:
wanneer 2 devices vanaf hetzelfde externe IP komen zou je ze elkaar hun interne ip kunnen geven om zo te proberen via het lokale netwerk te verbinden bijvoorbeeld

Als je op die tour gaat zijn er mooiere oplossingen. Zoek maar eens op UDP Hole Punching, wikipedia. Moet je wel van een stream verbinding afstappen en udp gaan gebruiken maar dan zijn de mogelijkheden wel uitgebreider.

Als je dit wilt gaan doen met een centrale server die alles relayed kan je volstaan met een kleine Virtual Server ergens in een data center. Voor een klein bedrag in de maand kan je dan al veel bereiken. En het relayen kan zou makkelijk zijn als een thread maken wat van socket1 de inputstream leest en het naar socket2 schrijft.

voor het gemak er even vanuit gaande dat je java spreekt als je voor de android wilt programmeren:

Java:

public class Relayer implements Runnable {
  private final Socket sender;
  private final Socket receiver;

  public Relayer(Socket sender, Socket receiver){
    this.sender = sender;
    this.receiver = receiver;
  }
  @Override
  public void run(){
    try {
      byte [] buffer = new byte[1024]; // arbitrary buffer size
      while (!Thread.isInterrupted()){
        // receive and send data
        int read = this.sender.getInputStream().read(buffer);
        this.receiver.getOutputStream().write(buffer,0,read);
      }
    } catch (Throwable ball) {
      // TODO: make some awesome error handling which closses both sockets and tries to send the quit singnal to participating members
    }
  }
}

[Woy]

ThaNOD schreef op donderdag 21 oktober 2010 @ 12:26:
[...]
Als je op die tour gaat zijn er mooiere oplossingen. Zoek maar eens op UDP Hole Punching, wikipedia. Moet je wel van een stream verbinding afstappen en udp gaan gebruiken maar dan zijn de mogelijkheden wel uitgebreider.

Maar Hole Punching is ook zeker niet waterdicht, dus je zult sowieso een fallback scenario moeten hebben.

[kinderpindakaas]

Ervan uitgaande dat mijn apps alleen gebruik maken van GPRS, kan ik er dan vanuit gaan dat ik dan gevrijwaard ben van NAT problemen?

@ThaNOD thanx voor je gedetailleerde reply.

[ Voor 15% gewijzigd door kinderpindakaas op 21-10-2010 17:08 ]

[Woy]

kinderpindakaas schreef op donderdag 21 oktober 2010 @ 17:08:
Ervan uitgaande dat mijn apps alleen gebruik maken van GPRS, kan ik er dan vanuit gaan dat ik dan gevrijwaard ben van NAT problemen?

Nee, juist op mobiele netwerken kun je er vanuit gaan dat het lastig is om een directe onderlinge verbinding te leggen.

[voodooless]

ThaNOD schreef op donderdag 21 oktober 2010 @ 12:26:
voor het gemak er even vanuit gaande dat je java spreekt als je voor de android wilt programmeren:

Dat kan nog veel makkelijker met een PipeInputStream/PipedOutputStream "Ranzige" threading dingen zijn dan niet nodig.

[Caelorum]

Woy schreef op donderdag 21 oktober 2010 @ 11:50:
[...]Maar zoals gezegd, kan dat tegenwoordig nogal wat problemen opleveren op mobiele netwerken, en ook bij gewone clients met NAT

Hmm daar had ik nog nooit van gehoord. Zal ik eens naar gaan zoeken ^^

[Voutloos]

KISS en begin eerst maar met een ouderwetsche client-server aanpak, zeker als je geen/weinig ervaring op dit gebied hebt. p2p zal in voorlopig altijd complexer zijn. Nadeel is dat je je server(s) meer belast, maar dit biedt ook een aantal voordelen: meer logmogelijkheden, meer controle tegen cheats, en het is een component welke je kan patchen zonder dat je allemaal verschillende clients aan een update moet helpen.

Anders gezegd: Welke zeer overtuigende reden heb je om aan p2p te denken? Hint: totdat je spel superpopulair is wint een besparing op hardware het bij lange na niet van de extra devtijd.

(dit is overigens een herhaling van deel argumenten uit Beginnen aan OpenGL )

[kinderpindakaas]

Na enig onderzoek kwam ik dit tegen:

When this chapter was originally written, the Android SDK included a comprehensive instant
messaging (IM) service (powered by GTalk) that offered access to the instant messaging frame-
work. This included the ability to send and receive text messages, set user status through pres-
ence, and determine the presence of IM contacts. Unfortunately, owing to security concerns the
IM API has since been removed, though it’s expected that later releases of Android will expose
developer access to an IM framework.

Kijk zoiets zou een ideale manier zijn van p2p communicatie waarbij de tussenliggende hardware door google verzorgd is. Spijtig dat dit er nu uit ligt.

[YopY]

kinderpindakaas schreef op donderdag 21 oktober 2010 @ 22:38:
Kijk zoiets zou een ideale manier zijn van p2p communicatie waarbij de tussenliggende hardware door google verzorgd is. Spijtig dat dit er nu uit ligt.

Dat is misschien handig voor het uitwisselen van relatief eenvoudige / kleine berichten, maar denk dat het al gauw problemen geeft als je echt gegevens probeert uit te wisselen. Er zal ook wel een flood protection op zitten, zodat je het niet meer dan X keer per Y tijdsperiode kunt gebruiken (je gebruikt per slot van rekening de diensten van Google).

[kinderpindakaas]

Met IPv6 kun je inmiddels ook via diverse probeertools van microsoft elke pc een publiekelijk ipv6 adres geven.
Dwars door alle routers heen.
Ik geloof dat het inmiddels in Windows 7 is ingebakken (Microsoft Teredo)
Mijn Android apps draaien niet 24/7 en ik wil zelf een game kunnen starten.
Dus wat dat betreft kan ik via teredo natuurlijk een publiek IPv6 adres maken en daar zelf wat op knutselen.
En de server sluiten als de game over is.

Maar een groot probleem is dat je pc direct aan het net hangt.
Nu is portscanning met 128bits ip adressen geen leuke klus, dus de kans is klein dat je doelwit zal zijn van aanvallers, maar toch.
En het is nog maar de vraag in hoeverre IPv6 al klaar is in Android.

[ Voor 3% gewijzigd door kinderpindakaas op 26-10-2010 23:10 ]

[Jaap-Jan]

YopY schreef op vrijdag 22 oktober 2010 @ 21:21:
[...]


Dat is misschien handig voor het uitwisselen van relatief eenvoudige / kleine berichten, maar denk dat het al gauw problemen geeft als je echt gegevens probeert uit te wisselen. Er zal ook wel een flood protection op zitten, zodat je het niet meer dan X keer per Y tijdsperiode kunt gebruiken (je gebruikt per slot van rekening de diensten van Google).

Daar kan ik wel iets meer over vertellen. Je kunt zelf een XMPP- server opzetten (GTalk is in feite een XMPP- implementatie) die geen last heeft van zulke problemen. Openfire is een redelijk goede server.

Verder kun je alles kwijt in een XMPP- bericht: het is een XML- bericht en je kunt gewoon zelf extensies maken voor XMPP.

Verder heeft Android al een paar XMPP- clients: smack is ernaar geport en Jabberoid werkt redelijk, maar de eerste is aan te raden.

Weet wel dat XMPP geen p2p is: alle communicatie verloopt via een centrale server. Bestandsuitwisseling verloopt wel via 'DCC' (niet echt DCC, maar wel vergelijkbaar).

[kinderpindakaas]

Super tip Jaap-Jan

Nu komen we in de buurt van een oplossing.
Als er nu zoiets bestond via apache server, dan had ik mijn huidige hosting daarvoor kunnen gebruiken.
Maar er zullen vast wel hostingproviders bestaan die zo'n server aanbieden.
Thuis een server opzetten of een eigen server in eigen beheer bij een hosting zie ik zelf niet zo zitten.
Dan moet je qua security aardig wat kennis in huis hebben.

EDIT: nog mooier, er zijn gratis public XMPP servers waar je een account kunt krijgen.
Helemaal top dit. Als het ook daadwerkelijk voor stukjes data gebruikt kan worden?
Het lijkt erop dat xml layout wel fixed is en dat ik mijn data tussen <message></message> kwijt moet

[ Voor 25% gewijzigd door kinderpindakaas op 27-10-2010 15:43 ]

[EddoH]

Sorry ik kan iets over het hoofd zien, maar wat verschilt deze aanpak nou werkelijk van een client -> server -> client oplossing zoals al meerdere malen aangedragen in dit topic?

[Cartman!]

Dat lijkt me wel t minst van je problemen

Wellicht kun je ook kijken naar APE: http://www.ape-project.org/home.html Het is een long polling methode die werkt via een kleine webserver die geoptimaliseerd is voor veel simultane requests. Je kunt er ook channels tussen 2 personen mee maken (verbinding loopt wel via de server nog). Wellicht is dat simpeler implementeren van XMPP en voldoet het aan je eisen, zomaar een idee