Hello everyone~
I have a problem to solve~
I have created a server that every one can connect to this server.
The function of The server is in order to transfer message from one client to another client.
I don't known when the other client send the message to the client.
I use Delphi-7 to develop the program.
I didn't find any TCPClient object to listen the message which the TCPServer send.
Please give me your point of views~thanks :)
Servers don't initiate conversations with clients. If your messaging clients don't already have open connections with the server, and the server needs to notify the client that it has a message, then the client program needs to have a server component so that it can listen for new connections from the message server.
One alternative is for the clients to keep persistent connections open with the server. When a message arrives, the server can send a notification to the appropriate client because it already has a connection open and the client is waiting for a response from the server.
Related
As per https://datatracker.ietf.org/doc/rfc6120/?include_text=1 and 10.1. In-Order Processing
How is Ordered Message Delivery ensured across all items in roster?
Is it done at server or client side? If it is on any side, are newer messages being waited upon older messages with a timeout?
Does it use an incremental sequence number for ordering guarantees?
On client re-connect, how does client know what to pull from server? Does the client send last msgIds of all items in roster? or does Server keep the QOS data and client state for each device ?
First of all, As XMPP uses TCP transport protocol it ensures the server receives the data in the same order the client sends it.
As per TCP docs:
TCP guarantees delivery of data and also guarantees that packets will
be delivered in the same order in which they were sent
ejabbred is an XMPP server, the raw data received over the TCP must be compliant with the XMPP protocol and the same being verified XMPP server.
In XMPP protocol client can able to send messages after it has done with session initiation, resource bind, and authentication, etc..
These messages are being processed in the order the client sends it and routes to its recipients. If recipients are offline it push and pop to database the same order for later delivery.
Here ordering guarantees mostly ensure by the TCP network stack.
Imagine an MQTT broker with remote clients connected, which continuously send QoS 2 data - the standard situation. Clients are configured with "cleansession false" - they have a queue to send messages in case of a connection failure.
On the server, local clients subscribe to topics to receive messages.
Server load:
Launch the MQTT Broker
Running local clients
Connecting remote clients and receiving data from the queue
What if the third point occurs before the second? Are there standard solutions? How not to lose the first messages?
Assuming you are talking about all later reboots of the broker, not the very first time the system is started up then the broker should have stored the persistent subscription state of the clients to disk before it was shutdown and restored this when it restarted. This means that it should queue messages for the local clients.
Also you can always use a firewall to stop the remote client being able to connect until all the local clients have started, this would solve the very first startup issue as well.
According to MQTT Protocol 3.1.1, "A Client can only send the CONNECT Packet once over a Network Connection. The Server MUST process a second CONNECT Packet sent from a Client as a protocol violation and disconnect the Client". But it confuses me that the server MUST disconnect the previous one or the new one?
I tested it with MQTT, and I used two sessions to subsribe the same topic with the same Client ID. Does it mean that the same client sends CONNECT twice? If it's true, it really confuses me.
The new subscriber'll cause the server disconnect the old one. It's diffirent with the protocol. When they old one disconnected, it'll try to send CONNECT and wait CONNACT packet. Then it turns to the new Client, and the server disconnects the previous new subscriber.....
So what does the protocol mean? The Server MUST process a second CONNECT Packet sent from a Client as a protocol violation and disconnect the old Client or the new Client?
You are confusing 2 separate events here.
Firstly if a single client sends 2 connect packets on the same network connection then the broker will disconnect that client.
The second instance you mention is 2 clients with the same client id. This will be 2 separate network connections even if from the same host. Each of these clients will send a single connect packet but because there will be a client id clash the first of the clients to send the packet will be disconnect when the second arrives
I'm developing a messaging system in Delphi. I'm using idTcpServer in my Server Application and idTcpClient in my client application. the client application pings the server every 10 seconds to see if the connection is active and tell the server to set the status of the user to Online. and also the user may send messages to his contacts. all these requests are followed by a response from server which i get by socket.readln command right after i send the request. for example for pinging the server:
TcpClient.socket.writeln('i am online');
if TcpClient.socket.readln = 'ok' then
begin
{commands}
end;
I also check for new messages using Long Polling. I send 'check for new messages ' + timestamp from tcpClient and then on the server, I check the database for new messages newer than the timestamp i recieved in a While loop so when there is a new message the loop breaks and notification is sent to the client.
But this system doesn't work for me. Sometimes I get the responses intended to be for checking for new messages when the client application is pinging the server.
I have developed the same system in php without a problem. but here there must be a problem.
I think it is not asynchronous. what should I do?
Regarding the check for new messages request, the server should not be looping waiting for new messages to arrive. Either there are new messages available at the time of the request or there are not. Get the request, do the query, report the result, and move on. The client can send a new check for new messages request periodically. Alternatively, have the client tell the server one time that it wants new messages, and then the server can actively push new messages to the client in real-time as they arrive on the server, instead of polling for them (similar to IMAP's IDLE command).
I would suggest you redesign your communication protocol to run asynchronously. Most modern IM services are asynchronous. When the client sends a request, do not expect a reply right away. Just let the client move on to other things. Have it run a separate timer/thread that reads all inbound data. When a reply does arrive, the client can act on it. If needed, include an identifier in the request that gets echoed in the reply so the client can keep track of the requests it sends. This also allows the server to use asynchronous processing on its end, so if a request takes a long time to run, the server can push it off to another thread/process and continue processing other requests in the meantime. Send the final reply when it is ready.
i went through this question
Lost messages over XMPP on device disconnected
but there is no answer.
When a connection is lost due to some network issue then the server is not able to recognize it and keeps on sending messages to disconnected receiver which are permanently lost.
I have a workaround in which i ping the client from server and when the client gets disconnected server is able to recognize it after 10 sec and save further messages in queue preventing them from being lost.
my question is can 100% fail save message delivery be achieved by using some other way i know psi and many other xmpp client are doing it.
on ios side i am using xmppframework
One way is to employ the Advanced Message Processing (AMP) on your server; another one is to employ the Message Delivery Receipts on your clients.
The former one requires an AMP-enabled server implementation and the initiating client has to be able to tell the server what kind of delivery status reports it wants (it wants an error to be returned if the delivery is not possible). Note that this is not bullet-proof anyway as there is a window between the moment the target client losts its connectivity with the server and the moment the TCP stack on the server's machine detects this and tells the server about it: during this window, everything sent to the client is considered by the server to be sent okay because there's no concept of message boundaries in the TCP layer and hence if the server process managed to stuff a message stanza's XML into the system buffers of its TCP connection, it considers that stanza to be sent—there's no way for it to know which bits of its stream did not get to the receiver once the TCP stack says the connection is lost.
The latter one is bullet-proof as the clients rely on explicit notifications about message reception. This does increase chattiness though. In return, no server support for this feature is required—it's implemented solely in the clients.
go with XEP-0198 and enjoy...
http://xmpp.org/extensions/xep-0198.html
For a XMPP client I'm working on, the following mechanism is used:
Add Reachability to the project, to detect quickly when the phone is having connectivity problems.
Use a modified version of XEP-0198, adding a confirmation sent by the server. So, the client sends a message, the server confirms with a receipt. Later on, the receiving user will also confirm with a receipt. For each message you send, you get two confirmations, one from the server, one from the client. This requires modifications on the server of course.
When the app is not connected to the XMPP server, messages are queued.
When the app is logged in again to the XMPP server, the app takes all messages which were not confirmed by the server and sends them again.
For this to work, you have to locally store the messages in the app with three possible states: "Not sent", "Confirmed by server", "Confirmed by user"