android - Push notification from server to client using UDP -


we want build simple data sharing application 2 android mobiles (or computers) connected on internet (wifi/network) upload , download data server through https.

e.g. wants send data b. trigger "put" https api , upload data bucket of b. b call "get" https api , download content.

now issue communication between , b demand based. can happen after minutes, hours or days. if go https way, have keep b in long polling server eat out resources days when there no message. if poll every minute or 2 communication not happen in near real time.

to counter problem, have come following idea:

  1. whenever mobile registers internet, creates udp port , binds it
  2. it makes 1 time https connection server , sends ip address , port
  3. there can optional dummy data exchange between server , client using udp (to , from)
  4. after client doesn't have active connection , remains on same internet; continuously waits on udp
    port data received; if internet changes again repeat step-1
  5. when data received given client, server sends predefined dummy udp data client wake call. data continuously sent until client bucket read via https
  6. upon identifying data received on udp, client makes https connection server , reads intended data bucket , closes; server identifies , stops udp

in theory solution looks fine. internet came across following problems require answers:

  • what kind of ip address , port should sent server client? isp/network provided ip or else?
  • how server identify exact client send udp data? e.g. if 2 mobiles on same internet have same ip , ports
  • in c socket library, there 2 ways of udp connections: (1) connect() , send()/recv() (2) directly sendto()/recvfrom() using ip addresses. should used in scenario?

besides above question, improvement on actual way of "push notification" described above welcome.

you need take care of clients behind nat, can use udp hole punching.

let , b 2 hosts, each in own private network; na , nb 2 nat devices globally reachable ip addresses eipa , eipb respectively; s public server well-known globally reachable ip address.

  1. a , b each begin udp conversation s; nat devices na , nb create udp translation states , assign temporary external port numbers epa , epb
  2. s examines udp packets source port used na , nb (the external nat ports epa , epb)
  3. s passes eipa:epa b , eipb:epb a
  4. a sends packet eipb:epb.
  5. na examines a's packet , creates following tuple in translation table: {source-ip-a, epa, eipb, epb}
  6. b sends packet eipa:epa
  7. nb examines b's packet , creates following tuple in translation table: {source-ip-b, epb, eipa, epa}
  8. depending on state of na's translation table when b's first packet arrives (i.e. whether tuple {source-ip-a, epa, eipb, epb} has been created time of arrival of b's first packet), b's first packet dropped (no entry in translation table) or passed (entry in translation table has been made).
  9. depending on state of nb's translation table when a's first packet arrives (i.e. whether tuple {source-ip-b, epb, eipa, epa} has been created time of arrival of a's first packet), a's first packet dropped (no entry in translation table) or passed (entry in translation table has been made).
  10. at worst, second packet reaches b; @ worst second packet b reaches a. holes have been "punched" in nat , both hosts can communicate.

Comments

Popular posts from this blog

How has firefox/gecko HTML+CSS rendering changed in version 38? -

javascript - Complex json ng-repeat -

jquery - Cloning of rows and columns from the old table into the new with colSpan and rowSpan -