I am looking for an efficient way to feed a log file via the network (a demon of sorts). Each packet being a number of lines from the log file so that they can be processed from the other end. It is important for the server to be independent from the client meaning that it should be able to 'hold' the packets to be sent when the client is connected.
Note : I am aiming for a two-way communication, not a broadcast.
You could try using message queue middleware e.g. RabbitMQ. Its a nice way to decouple two systems like you describe. The message broker (RabbitMQ) will queue messages until the client/server connects and consumes them. You can have one queue for messages for the server and another queue for responses destined for the client. You could run RabbitMQ broker only on the server or you can have one on the client as well and shovel messages between them.
Related
we are a group of kids in middle school trying to implement a program in java that going to be like a chat server under the network
, we have one server outside the network and every client inside the network of the school
we want to know how could we send 1 packet from the server to every client in the network because behind that router there are many computers(clients).
you have tow option here:
broadcasting
multicasting
I prefer multicast because it is more effective and doesn't disturb every computer in the network.
How Does It work?
Multicasting is the ability to broadcast a message to a group of listeners in a single transmission.
A good analogy of multicasting is radio, Thousands of people can tune in to a single broadcast event and listen to
the same message, Computers can do similar things when sending messages to listeners.
A group of client
machines can tune in to the same address and port number to receive a message that a server broadcasts
to that address and port.
The Java language provides multicasting functionality via datagram messaging.
Datagrams are independent, nonguaranteed messages that can be delivered over the network to clients.
(Being nonguaranteed means that the arrival, arrival time, and content are not predictable.) Unlike
messages sent over TCP, sending a datagram is a nonblocking event, and the sender is not notified of the
receipt of the message.
Datagrams are sent using the User Datagram Protocol (UDP) rather than TCP. The
ability to send multicast messages via UDP is one benefit over TCP, as long as the ordering, reliability, and
data integrity of the message are not mission-critical.
check 1 2 3 for more information about the topic
I'm currently developing a Java WebSocket Client Application and I have to make sure that every message from the server is received by the client. Is it possible that I lose some messages (once they are sent from the server) due to a connection interruption? WebSocket is based on TCP so this shouldn't happen right?
It can happen. TCP guarantees the order of packets, but it does not mean that all packets sent from a server reach a client even when an unrecoverable trouble happens in an underlying network. Imagine someone pulls out your LAN cable or switches off your WiFi access point at the worst timing while your application is communicating with your server. TCP does not overcome such a trouble.
To ensure that every WebSocket message sent from your server reaches your client, you have to implement some kind of SYN/ACK in the application layer.
TCP is a guaranteed protocol - packets will be received in the correct order by the higher application levels at the far end (this is as opposed to UDP which is a send and hope protocol).
Generally speaking TCP should be be used for connections where all the data must arrive correctly at the far end. UDP is used where a missing packet can be dropped without significant issue (e.g. streaming services, NTP updates)
In my game, to counter missed web socket messages, I added an int/long ID for each message. When the client detects that something is wrong in the sequence of IDs it receives, the client will request for new data from the server to be able to recover properly.
TCP has something called Control Flow- which means it provides reliable, ordered, and error-checked delivery.
In other words TCP is a protocol that checks constantly whether the data arrived.
This protocol has different mechanisms to ensure that.
You can see the difference between TCP and UDP (which has no control flow) in the link below.
Difference between tcp and udp
I understand JMS as depicted by the following diagram:
(source: techhive.com)
Is there any way for me to access the underlying database using JMS or some other thing? Further, the JDBC connections that the JMS server maintains, can I add new connections in it so as to access other databases also and do CRUD operations on them? If yes, how?
Where did you get this from?
Normally JMS is used to send messages to queue (or topics). You have message producers that push messages in the queue and message consumers consume them and process it.
In your exemple it seems that you have multiple queues. One for the messages that need to be processed, and one for each client to retrieve the result the processing of its messages.
With JMS Server you don't necessarily have a database behind. Everything can stay in memory, or can be written to files. You will need database server behind only if you configure your JMS server to be persistent (and to assure that even if server/application crash your messages won't be lost). But in that case you will never have to interact with the database. Only the JMS server will and you will interact with the JMS server sending and consuming messages.
I am doing a project of Restaurant ordering system in that I gave order by using different client and process that order and that order can send different system, e.g:
kitchen1
Kitechn2, and
kitchen3
First I can create different client by using rmi threading concept an and they can send (means all client) data to my server i want to sent that data into different client
How can I do that? I do create different client and send data to the server suggest how can I do that?
RMI is a synchronous (request/response) protocol - the client sends a request to the server, which it can respond to.
The server cannot arbitrarily send more data to the client.
The simplest way to asynchronous communication in Java via JMS using a message broker like Active MQ.
The process would go something like this:
the server starts and connects to its incoming request queue.
client 1 creates a temporary queue and registers with the server via the request queue passing the name of its temporary queue.
the server stores the client and the name of its termporary queue.
client 2 does the same and server stores the client and the name of its termporary queue.
client 1 sends a message to the server causing the server to send a message to client 2, which is does via the temporary queue that client 2 registered with the server.
client 2 reponds to the server causing the server to send a message to client 1, which is does via the temporary queue that client 1 registered with the server.
This can go on until one or both client shuts down, at which point their temporary queue are closed and the server can no longer send messages to that client (though it's best the client de-registers itself).
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.