Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I wanna program my own renderfarming tool in Java for the Blender render engine..
But know i wanna know what is better for doing that: TCP-IP or UDP?
Thanks
I assume you want to have the reliability for your renderfarm, so data that is sent to the user contains the exact quality he or she expects, without anything weird that occurs because a packet is missing. You definitely don't want frames being skipped or sloppy. So I would suppose TCP-IP is the better choice here.
Also see:
When is it appropriate to use UDP instead of TCP?
http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/
TCP/IP is a reference model whereas UDP is a protocol in this reference model. So, basically you can't compare these two. As, IP is another protocol in this model, at network layer, i think you mean to compare TCP and UDP, as they both belong to same layer, transport layer.
Which protocol is better, depends on what you want to do. For some requirements, TCP is better, for some, UDP.
TCP is a slow but reliable (ensuring that data is delivered) and connection-oriented protocol whereas UDP is fast but un-reliable and connection-less protocol.
TCP should be used when you need the data to be delivered surely (like downloading an application). UDP should be used if you need to deliver data most of the times(like sound or video chatting). By most of the times, we mean that while sending thousands of small data units, we can manage if we miss a few of them.
I hope, now you can decide which protocol to choose for you job.
It depends on the type of application that you are going to use. Make a note that TCP and UDP are transport layer protocols and do not mix it up with network layer protocol (IP).
TCP protocol :
It is a connection-oriented streaming procotol . It is Heavy weight as it does 3 way handshake for connection establishment, flow control for network congestion , re-transmission for error correction and also ensures ordered packet delivery.
You can select TCP for following applications :
Applications that can accept delay but cannot compromise on packet loss or ordering of packets. (i.e, it is suitable for delay insensitive applications and for reliable packet transfer applications.)
Example for applications using TCP :
FTP
HTTP
UDP protocol :
It is a message based connection-less protocol. It is Light weight as it does not have handshake mechanism for connection establishment or flow control for congestion or re-transmission mechanism. Also, it need to worry about the order of the messages.
You can select UDP for following applications :
Application that can tolerate packet loss or un-ordered packet delivery but cannot compromise on delay or jiter. (i.e, it is suitable for real-time applications and for applications that do not worry about packet loss)
Application that do multicast
Application that do small transactions (Example - DNS lookup, Heartbeat/Path monitoring communication messages, Logging)
Example for applications using UDP :
VoIP
DHCP
Related
Basically I am new to server and client programming in java , I google all the necessary resources to learn from this particular topic however I did not understand the difference between them.
What I Understand so far for these two is that Both of them can Handle Client Request, but I need to further know the benefits of each Class and what particular scenario or specific case where when can I used it efficiently.
Like for instance , I have a Server Client Program which is a subset of team-viewer in which The client program must send Screenshot to the server in every millisecond while the server is going to publish it from another connected client. The code is working but I found out ServerSocket consumes so much Heap although it delivers successfully to the servers and client as well. I also read a blog (The link is missing) that is related to my problem suggested that DatagramSocket is the solution because it does not execute Handshakes.
I am really concern of the Benefits and Disadvantage of these classes.
A ServerSocket is for accepting incoming network connections on some stream protocol; e.g. TCP/IP.
A DatagramSocket is for sending and receiving datagrams on some connectionless datagram / message protocol; e.g. UDP/IP
Supplementary questions:
Basically what is a datagram
A datagram is bunch of information sent in a single logical packet. For example, a UDP packet.
and does this mean datagram = lightweight packets ?
It depends on your definition of lightweight!
UDP datagrams are sent as IP packets. If a UDP datagram is too big for an IP packet, it is broken into multiple IP packets by the sender and reassembled by the receiver.
and what does connectionless [mean],
It means that no logical connection exists between the 2 parties. If a component IP packet of a UDP datagram is lost, the UDP datagram is lost. The receiver never knows (at the application level). There is no reporting of data loss and no retrying in UDP. This is typical "connectionless" behavior.
does it mean Data might get lost during transmission?
Basically, yes. If you want reliable / lossless data transmissin the event that a datagram or on you should use ServerSocket and Socket; e.g. TCP/IP streams.
However, be aware that even with a (bare) TCP/IP stream, data delivery is not guaranteed:
If there is a network failure, or if either the sender or receiver has a failure, then a connection can be broken while data is in transit. That will result in data loss ... for that connection. (Sockets do not support reconnecting.) If the sender and/or receiver are still alive they will typically be informed that the connection has been broken, but they won't know why, or how much data was lost in transit.
It is possible for data to be corrupted in transit in ways that TCP/IP's error detection cannot spot. The receiver won't know this has happened.
Both of these issues can be addressed at the application protocol level; e.g. using message queues for the first and strong encryption and strong checksumming for the second.
Concerning your attempt to use ServerSocket.
The code is working but I found out ServerSocket consumes so much Heap although it delivers successfully to the servers and client as well.
You are doing something wrong. If you use the API appropriately the memory overheads should be insignificant.
My guess is that you are doing one or more of the following:
Opening a new connection for each client / server interaction
On the server side, creating a new thread for each connection
Not closing the connections.
I also read a blog (The link is missing) that is related to my problem suggested that DatagramSocket is the solution because it does not execute Handshakes.
Handshakes won't cause significant memory consumption.
TCP/IP stacks don't typically do handshakes by default anyway.
You say you have looked on google, but there are several pages on google that address your question directly. There are several that have the same title as your question. You have even indicated that you understand some of the difference between them by using the [tcp] and [udp] tags on your question.
The difference is one uses TCP communication protocol and one uses the UDP communication protocol. Perhaps your question is not one about Java but about how the internet, computer networking, and the communication protocols work?
TCP is a connection oriented reliable delivery protocol.
UDP is a connectionless unreliable delivery protocol.
What this means is you have to decide which is important, speed or reliability.
Is the data such that it must not be corrupted in transit? If it is then you must use TCP or a serversocket.
If the data must arrive by the fastest method, even at risk of getting lost, then you must use UDP or a datagramsocket.
If you need more explanation to understand you should take a course on computer networking.
I'd like to implement a function of realtime message such as chatting in facebook but several questions confuse me:
1. To reduce overhead of server and make it really 'realtime', I should use a full-duplex way of communication like socket instead of Ajax, is that right?
2. If I use socket, which protocol should I choose, TCP or UDP?
3. Assuming that I am using TCP, will server keep trying to resend the lost packages so that it would take much overhead?
4. What if the network failed in a communication between server and a client? Will the socket close it self or I should handle with several kinds of network conditions?
Can anyone help?
You can use WebSockets. XMLHttpRequest is probably obsolete now for anything real-time (because it's not real-time), though you could fall back to using it for people who use a browser that doesn't support WebSockets
Use UDP if the information you are sending is only valid for the time it is sent, for example in games that would be the position of the players (you don't care to receive the position they were in 5 seconds ago). Besides, you can't use UDP with WebSockets
For anything other than that, use TCP (unless you do hole punching to achieve p2p), because loss of data is probably bad for you, and TCP handles that.
You would have to check for and resend lost data manually with UDP anyway, unless failure in communication is acceptable by you
You will get an IOException. If the connection was closed improperly the exception will be thrown after a timeout of unresponsiveness that you are able to change according to your needs. This is assuming you use TCP, otherwise you should figure out yourself when you consider clients connected or disconnected according to the responses/data you receive (or not receive).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am trying to set up a P2P instant messaging system, and while I haven't hit the issue yet, I expect I will have some issues if the client is behind NAT on a local LAN (read: Everyone.)
Let me explain the algorithm and you'll see what I mean. There are three components: A server and two clients - Client Alice wants to initiate a chat with Client Bob. The server only keeps track of who is online, but the actual conversation doesn't go through the server (for privacy for the clients)
So, Alice and Bob both sign in to the server - Connecting to the server's static listening port from an ephemeral port. They tell the server what static port they are listening on for incoming chat requests. Alice asks the server how she can contact Bob. The server responds with the ipaddress and listening port, among other things. Alice sends the request to Bob on that IP address and port to establish the connection. Hope that makes sense.
If Bob is behind NAT, then sure he can talk to the server because he's the one who starts the communication. But Alice's request won't get to him because the NAT relationship hasn't been set up yet for the port he's listening on for chat requests, from Alice's IPaddress.
Is there some kind of black magic that someone knows to make this work? Will it be a non issue? Development isn't that far along, I haven't actually hit this problem yet.
To state the obvious, I don't want to have to make end users configure port forwarding for their listening ports.
For the aforementioned black magic, client and server are both in java, but I'm just generally after the algorithm (and if it's even possible)
Check ICE.
Most P2P frameworks, like JXTA in Java, use the principle of relay servers.
Say A wants to connect to B and B is behind a firewall.
- both A and B establish ** outbound ** synchronous (or full duplex/websockets) connections to Relay Server R
- A signals to R that it wants to transmit data to B
- R 'binds' the inbound connection from A to the outbound connection to B (the synchronous HTTP response to B for instance)
- A sends data to R which is relayed to B
The key thing here is that all connections are established outbound (an usually using a friendly firewall protocol like HTTP on well known ports)
Things get obviously a bit more involved when you have distributed relays; you then need 'routers' that maintain routes to various peers via the relays which rely on Distributed Hashmaps (DHTs) to maintain the information.
There is no black magic. If both clients are behind NAT the message has to go through a third party (the server).
And I would consider using such architecture for all communication if it's only about text messages (you can think of some kind of encryption if privacy is an issue). The server (or servers) will be more loaded but you get simpler (and in some cases more reliable) architecture. For instance, if Alice sends message to Bob, and Bob has some network issues, the server can queue and keep the message for some time and deliver it later (even if Alice goes offline). Another thing is conference (group) chat. Handling it with P2P only is much more challenging (but can be very interesting). But if all clients are behind NAT you get the same problem.
I would also strongly suggest implementing an application-level acknowledgment mechanism for all transmitted and received messages (both from client and server). Protocols such as TCP/IP are not reliable enough.
The point of my question is to ask if it is accepted to use both TCP and UDP to communicate between client and server.
I am making a real-time client server game with parts of the communication that need to be guaranteed (logging in, etc..), but other parts will be ok to lose packets (state updates, etc). So, I would like to use UDP for most of the data communication but I do not want to have to implement my own framework to insure that my control communication (logging in) is guaranteed.
So, would it be reasonable to initially use TCP to manage a connection, and then on a separate port send data communication pack and forth?
You should absolutely do it that way (use TCP and UDP to accomplish different communication tasks.) And you don't even have to use two different ports. One will suffice. You can listen to the two different protocols on the same port.
It is quite reasonable and already used in mainstream. Even when browsing the Web, DNS operations are UDP-based and HTTP connections are TCP-based.
Keep in mind that you should either consider the two connection types to be completely independent or employ additional measures to properly handle any inter-dependencies. TCP connections can have timing issues at the OS and network levels and UDP connections have packet loss issues. You should take specific measures to avoid deadlocks and performance problems when the TCP part of your application stalls or a UDP packet is lost.
It is not only accepted but is widely used. As a good example, BATS Exchange is using this approach in their market data distribution system, to implement a recovery mechanisms.
I'm writting a java application, and I need to quickly discover any other running clients on any wired or wireless local networks in order to establish a TCP connection.
what's the best way of doing this? Are there libraries or code snippets that would do this?
Multicast UDP is a good way of doing this. It's used in a couple of technologies that support automatic discovery of networked devices over local IP networks (UPnP and ZeroConf).
Multicast UDP is not TCP, but it is still based on IP and, so, uses the same addressing mechanism i.e. IP addresses. Quite often it is compared to radio broadcasting i.e. a multicast sender only needs to send 1 message (i.e. it is like a broadcast) but only clients that are "tuned-in" to the multicast channel will receive it.
You can do a quick search on google or wikipedia for these as a starter, but the basic idea is as follows:
when a client starts, it sends out a multicast UDP "hello" message to some pre-specified multicast address and port (e.g. UPnP uses 239.255.255.250:1900)
existing clients are listening for incoming multicast "hello" messages on the specified address and port - when a client receives one, it sends a response to the sender
the client sending the "hello" message receives a response from each existing client on the network and is now aware of the IP address of each client
If you are looking for libraries to use, UPnP libraries can tend to be a bit heavyweight and a lot of folk generally don't like them, so ZeroConf might be a little more suitable. I don't know of any java implementations of such things but I'm sure you can find some with a little digging around.
A network scan can be very long, even longer on wireless networks. If you need them quickly thru Java you may implement a "meeting point" server on your network. This server listen to a predefined port, clients register on the server on startup and the server can distribute information about the clients on request.
HTH.
I guess you need to do a scan on your application's port on all IPs in your subnet.
Just what are the available IPs - or what is your subnet for that matter?
I'm afraid determining that could turn out to be impossible as the network is designed to be transparent to your application.
So, i'd use brute force: pick your IP and change the last byte. Might be too much, might be not enough though.
Or you send a broadcast (which usually would be targeted at x.x.x.255) and see who answers.
See Datagram Broadcasting and Multicasts. But i think that's not TCP/IP anymore.
There is a JGroups toolkit for reliable multicast communications. It allows automatic discovery of additional clients using Multicast techniques as described in other answers.
It also provides communication APIs on top of multicast sockets.
It is used in a number of projects such as JBoss, Tomcat and more to provide an infrastructure for distributed cache. See more here.