I am working on a project in which I can see webcam images from the people who is in front of the door on my Android app.
But I am getting a bit confused. I've managed to setup a connection with a service on my phone to a server which handles the image sending.
But i only want to get images from the server when someone presses the doorbell, so I need to send a notification or something to my app so I know there is one in front of the door, and I want to decide if I want to answer his call or not.
Now this is why I am confused: if I open the tcp socket in the android service, how can I know that my server sends a 'call' message, because the tcp socket is openend when the service is created. Do I need to keep polling every second? Then there is still a little chance that I will miss the call message?
Or do I have to run the application as server and the doorbell as client, so the client request a connection?
Have a look at cloud to device messaging, c2dm , a lot more power efficient too. Built into android.
https://developers.google.com/android/c2dm/
If the tcp socket is opened when the service is created, just send some appropriate message from the server to connected clients. If your client is connected, it will get it. You only need to poll if the client continually connects and disconnects, eg. like many HTTP 1 web services.
Related
I'm trying to make a communication between my App and the server side. The app needs to receive messages from the server because it's remotely controlled. It works as a Background Service.
I'm currently getting the messages from the external MySQL by using HTTPPost, doing requisitions every 20 seconds, but it spends much battery.
I tried doing a Socket connection to a server (build in java): device connects to the server every 20 seconds and close the conn when it just receive the data, but it also spends much battery.
Is there a way of receiving these messages instantly as Whatsapp does?
If the app is open it's most likely a socket connection. This is usually how messengers work.
In the background though it's most probably using push notifications (Check FCM - Firebase Cloud Messaging). This source of info can be unreliable so making a service with requests once a minute or two could be cool
In our messenger, we use long-live HttpsURLConnection as the main channel. The connection is hosted in Service and it is run in separate thread. In case of disconnect, we try to establish a new one. And we stop the service after our application is inactive for 2 minutes.
As the second channel, we use FCM.
This is what concerns messages. We also use WebRTC for multimedia data transfer. And we are going to use SIP calls to init voice- and video- call.
I have 3 devices android (1 server and 2 clients) connected via TCP.
Knowing that sometimes the server uses the open socket to contact the client, how can I manage the disconnections?
Indeed, in case of a short disconnection, only the client can restore the connection. The server can't send a message to the client anymore and has to wait for the client's call. Right?
So, I think I have 2 options:
Force the client to maintain the contact with the server, sending an "are you there" message every second to him. Thereby, if a disconnection occurs, it will restore the connection as soon as possible.
Use a peer to peer structure. Both (client and server) can "call" the other when he wants.
While the first solution seems heavier for the network, and the second more complicated to set up and maintain. What do you recommend?
I am looking to build an instant messenger in Java.
Clients will connect to the server to log in.
They will start a conversation with one or more other clients.
They will then post messages to the server that will relay the messages to all the clients.
The client needs to be continually updated when users post messages or log in.
so the way I see it, the client needs to run a server itself in a separate thread so that the main server can send stuff to it. Otherwise the client will have to the poll the main server every xyz seconds to get the latest updates. And that would need a separate thread anayway, as that would be purely for getting updates whereas the 'main' thread would be used for when the client initiates actions such as posting messages/inviting others to conversations etc...
So anyone recommendations on how to write this instant messenger? Does it sound like a good idea to make the connection a 'two-way' connection where both the client and server act as servers? Or is polling a better option? Anyone know how the IRC protocol does this?
There's no real advantage of having 2 connections unless they can be handled independently (for example receiving / sending a file usually done in a separate connection). A connection itself is already a two-way communication channel so it can be used to both send and receive messages, events etc. You don't need to poll server since client is able to maintain persistent connection and just wait for data to appear (optionally sending periodic PING-like message to ensure connection is alive).
IRC uses a single connection to server to exchange text commands. For example one of the main commands:
PRIVMSG <msgtarget> <message>
This command can be originated either by client or by server. Client sends PRIVMSG to notify that it wants to deliver message to one or more destination (in IRC this either user(s) or channel(s)). Server's task here is to properly broadcast this message to appropriate clients.
If you're using raw InputOutput streams then yes this is a good way of doing it. You create one thread on the clientside that acts in a similar fashion as the server thread - waits for any incoming updates and when it does it updates the client. I wouldn't call it a server though. So you'd ideally have 2 TCP/UDP connections one for requests made by the client and one to notify the client of server changes.
This solution in an enterprise environment would probably be done through some kind of messaging framework such as Spring Integration but dig deep enough and it will essentially be a similar way to how you mentioned.
Do you need a fully custom protocol or would it be sufficient to use the XMPP? There are several open source libraries implementing XMPP.
http://xmpp.org/xmpp-software/libraries/
e.g. http://www.igniterealtime.org/projects/smack/
For me, to develop instant messaging service, I will use websocket protocol instead of normal java socket because the normal socket can not work well with HTTP protocol and moreover some network providers and firewalls banned custom ports. If you develop it in normal socket, your service could not be accessed by web clients.
Did you plan to develop the instant messaging service yourself? How about using other protocols such as Jabber?
Can a J2ME app be triggered by a message from a remote web server. I want to perform a task at the client mobile phone as soon as the J2ME app running on it receives this message.
I have read of HTTP connection, however what I understand about it is a client based protocol and the server will only reply to client requests.
Any idea if there is any protocol where the server can send a command to the client without client initiating any request?. How about Socket/Stream based(TCP) or UDP interfaces?.
If the mobile device doesnt allow you to make TCP connections, and you are limited to HTTP requests, then you're looking at implementing "long polling".
One POST a http request and the web-server will wait as long time as possible (before things time out) to answer. If something arrives while the connection is idling it can receive it directly, if something arrives between long-polling requests it is queued until a request comes in.
If you can make TCP connections, then just set up a connection and let it stay idle. I have icq and irc applications that essentially just sit there waiting for the server to send it something.
You should see PushRegistry feature where you can send out an SMS to a specific number have the application started when the phone receives that SMS and then make the required HTTP connection or whatever. However, the downside of it is that you might have to sign the application to have it working on devices and you also need an SMS aggregator like SMSLib or Kannel
You can open socket connection and implement "Hide" (or "Minimize") functionality in your app. Call this to hide:
Display.getDisplay(MyMIDlet.instance).setCurrent(null);
Listen to the server in a loop, and if you receive some message, popup the applicaion by calling this from canvas:
Display.getDisplay(MyMIDlet.instance).setCurrent(this);
But it dosen't work on all devices.
Socket push are supported by j2me. But it could work only if your server could deliver data to your mobile phone. Most likely that operator gateway don't allow to do this.
Maybe it would be possible if your mobile has static external IP address - some operators could provide this for $$.
I'm a bit confused. I would like to send messages from my Red5 Server to my Flash App... but I don't find any information how to do that...
Can anyone help me?
This looks like a good start:
http://www.red5tutorials.net/index.php/Tutorials:Getting_Started_With_Red5_Server
See near the bottom for their simple flash client.
Edit: More options given now that it's clear we're going from server-client:
Looks like you need to do something like this:
http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/net/NetConnection.html
and
http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/net/NetStream.html
which would mean using "NetStream.play()" to get the server to stream data to the client.
Or you might want to look at the Socket class(es) and manually create a direct socket connection between the client and server.
Keep in mind here, I've never used Red5. Just trying to help :)
For anyone who didn't find an answer until today: I am working in red5, and you can send message from red5 to flash by a RemoteSharedObject in AS3 connecting to a sharedobject in red5.
Server Code:
ISharedObject so = getSharedObject(scope, "chat");
so.setAttribute("message","Welcome");
Client Code:
so = SharedObject.getRemote("chat", connection.uri, false);
so.connect(connection);
so.addEventListener(SyncEvent.SYNC, syncChatHandler);
private function syncChatHandler(event:SyncEvent):void {
Alert.show(so.data.message,"Information");
}
This code will show an alert on users connected with the message "Welcome". From here read a lot of documentation and use your imagination.
Hmm, by definition, the server serves and the client requests. So to create a push scenario, you still have to first initialize a connection from the client to the server. Then you can leave the connection idle until you need to send something to the client. Polling is the other method, where the server holds on to the messages and the client frequently checks in to see if new messages are available. A server cannot initiate a connection to the client. That would make the client a server. In other words, you could have the flash client register it's current IP with the server and open up a port itself, establishing itself as a server. Then the Red5 server becomes a client and can connect to the server inside the flash client. But I imagine many security restrictions will prevent your flash program from acting as a server in the real world.