I want to create a voice chat application in pure java socket programming.
I used UDP protocol to transfer recorded voice from one client to another but when i test it over the internet voice is not comming continuously.
As i am new to this voice chat application, someone may suggest what should i do for getting continuous voice.
The Scenario is like this.
Flow of voice chat as this shows only one way communication-
FLOW of data
Client1------------------------------>> Server ------------------------------------>>Client2
Client1:
Reading 1KB voice buffer from TargateDataLine then create a voice packet and sent to server.
Server: Receive from client1 and then send to client2.
Client2: Receive the UDP packet and get voice data then play.
Also facing the bandwidth up and down problem.
What should be the minimum bandwidth to use voice chat. Ex- skype required 30KBPS udloading/downloading speed.
Thanks in advance.
In order to establish a connection between two or more users for peer-to-peer communication you need a signaling server as well as STUN/TURN servers.
You can code your own ones or use a ready backend solutions like ConnectyCube and concentrate on client-side implementation. Here are some WebRTC video chat code samples for your reference as well.
You should send the packets directly between the clients. The relaying of packets through the server is adding more delay to it. Simply send it from client1 to client2.
The Answer is pretty simple you should use tcp protocol. Coz udp sends the packet but doesn't ensure that the packet was received by the target. but tcp protocol ensures it and you will get a stable connection with cost of some speed reduced in transfer of data.tcp vs udp
Related
I'm creating multiplayer server - client using UDP method. In UDP, there is only one way to receive every packet which is socket.receive(packet). If there are many clients send data at the same time, how can one socket.receive(packet) can handle it all and fast? Thankyou
I need to implement client/server instant messenger using pure sockets in Java lang.
The server should serve large number of clients and I need to decide which sockets should I use - TCP or UDP.
Thanks, Costa.
TCP
Reason:
TCP: "There is absolute guarantee that the data transferred remains intact and arrives in the same order in which it was sent."
UDP: "There is no guarantee that the messages or packets sent would reach at all."
Learn more at: http://www.diffen.com/difference/TCP_vs_UDP
Would you want your chat message possibly lost?
Edit: I missed the part about "large chat program". I think because of the nature of the chat program it needs to be a TCP server, I cannot imagine the actual text content sent by users over a UDP protocol.
The max limit for TCP servers is 65536 connections at the same time. If you really need to go past that number you could create a dispatcher server that would send incoming connects to the appropriate server depending on current server loads.
You could use both. Use TCP for exchanging the actual messages, (so no data lost and streaming large messages, (eg. containing jpegs etc), is possible. Use UDP only for sending short 'connectNow' messages to clients for which there are messages queued. The clients could have states like (NotLoggedIn, TCPconnected, TCPdisconnected, LoggedOut) with various timeouts to control the state transitions as well as the normal message-exchange events. The UDP 'connectNow' message would instruct clients in 'TCPdisconnected' to connect and so move to 'TCPconnected', where they would stay, exchanging messages, until some inactivity timer instructs the client to disconnect for now. This would, of course, be unreliable and so you may wish to repeat the 'connectNow' message every X seconds for N times until the client connects. The client should, in any case, attempt a poll every X minutes, just in case...
It depends whether the user needs to know if the messages have been delivered to the server. UDP packets have no inherent acknowledgement. If the client sends an IM message to the server and it gets lost in transit, neither the client or the server will know about it.
(The short answer is "use TCP" ... but it is worth thinking through the design implications for yourself.)
TCP would give you reliability, which is certainly desirable when during instant messaging -- you would not want messages to be dropped during converstation.
However, if you intend on using group messaging, then you might end up using mulitcast. For such cases, UDP would be the right chioce since UDP can handle point to multipoint. Using TCP for multicast applications would be hard since now the sender would have to keep track of retransmissions/sending rate for multiple receivers. One alternative could be to use TCP for point-to-point chat and use UDP for group messaging.
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.
I want to program a game that involves a client-server option for a network.
For this, I need to be able to get a list of all people that are hosting a server on their computer but the Socket class requires a name of the computer. Is it possible to get this list and if so, then how?
Thanks you very much
You could use a MulticastSocket on the client to listen for broadcast UDP packets from the server. See Broadcasting to Multiple Recipients and have your server send one out every few seconds.
I have developed a application which involves billing users. To do this i have incorporated a GSM modem (gateway) that the SMS messages are sent through. This SMS message is sent to the user when he is billed with the bill details. The GSM modem is connected to a single computer but the billing can happen in other systems. How do I send an SMS notification for the changes that occur in the other systems, as the GSM modem is attached to a COM port on the computer*.
can we access the COM port of other system or shoould i use socket programming (with the machine with the modem(Server) listening for any connection, the sender has to send data in particular format and the server has to parse the data and send the message) or use Java RMI or is there any other solution.
Suggestions please....
Thank you
There are any number of solutions you can think up. The most common ones would be:
Communication with some kind of RPC, be it RMI, SOAP, plain HTTP, telnet, etc.
Using an SMS gateway such as Nordic Messaging’s EMG (probably overkill, though) or kannel (seems to be down currently).
We've got an SMS Gatway. We wrapped it in a J2EE-application with a webservice interface. That way we can send SMS from any of our applications. For the sake of java we made a little jar-file that talks to the webservice
SmsClient smsclient = new SmsClient();
smsclient.sendSms(from, to, message);
I built a similar system to this in the past where small embedded systems sat on a network and reported messages over the network to a central server that logged the messages and sent SMS messages when required.
I used a java socket listener that waited for UDP messages from the embedded units and the java program wrote to the GSM modem on the servers comm port. UDP was only used instead of TCP as it was simpler to configure on an embedded system.