I have a server and a client program. I am updating the number of clients as and when a client comes. However I am unable to show which client has closed after closing. Can anybody help me? I am using socketdescriptor to keep track of clients present.
I am also having different types of clients for which I am using threading concept.
When a client arrives, a Server class inheriting QTcpServer accepts connection and passes it a requesthandler class that inherits QTcpSocket. In this I am calling thread class for defining different types of clients. Here I am calling a function that updats client number in GUI.
However when I close a connection I am unable to identify which client closed and thus unable to updat in client.
How to overcome this issue?
void QAbstractSocket::disconnected() [SIGNAL]
is the way to go.
if for some case the clients are on the same machine, they must identify at the server anyway (a unique id or the type of application it is).
that might be done with a initial message to "tell the server" what kind of client is connected. that stored in a QMap<QTcpSocket*, MyClientType> and you can determine wich client disconnected and wich type it was.
cheers
Related
As what title said, i still confusing and turn around in deep-hole and get lost about one month in it. So i really need help.
I would like to create client-server online game, and separate Client and Server to different project with each other, and for understanding, i don't using any NetworkManager and script from demo project.
Why i do that ? I want client is always remote client, and server always dedicated server that mean no local client.
All communication until now i using custom message from MessageBase and it ok for me. But the problem come with spawn game object, sync with all remote client, i don't know how to do that.
The server just handle connection, message and send back to client so it just GUI only, then i want to ask that it MUST be share scenes at client ? Does it NEED TO DO IT ?
The client is a remote client, so how to sync movement, spawn, and etc to another client via server ? If i using transfer message base on MessageBase, it look so complicate than using SyncVar or Command. But i don't know how Server handle Command, because it separate different with Client. Can anyone help ?
AM I WRONG WAY ?
I have a C++ 0MQ application that does a bind() and sends messages using a PUSH socket. I want to ensure that these messages get sent to no more than one client.
Is there a way to allow just one client to .connect(), and then reject connections from all subsequent clients?
If your server application uses a ROUTER socket instead of PUSH, it has more control over the connections. The first frame of each message contains the id of the sender, so the server can treat one connection specially.
To make this work, the protocol has to be a little more complicated than a simple PUSH/PULL. One way is for the connections to be DEALER sockets, whose first action is to sent an "I'm here" message to the server. The server then knows the id of the connections, and treats the first one specially. Any other connections can be rejected with a "You shouldn't be here" message to the other connections, which of course they must understand and act on it by disconnecting themselves.
After the first "I'm here" message, the clients do not need to send any more messages. They can just sit there waiting for messages from the server, exactly the same as PUSH/PULL.
Yes, there is
While the genuine ZeroMQ messaging framework has lot of built-in features, it allows to integrate additional abstract layers, that can solve your task and many other, custom-specific, needs. So do not worry that there is not a direct API call for doing what you need.
How to do it?
Assuming your formal architecture is given, the viable approach would be to re-use networking security trick known as "port-knocking".
This trick adds an "introduction" phase on a publicly known aPortToKnockAt, after which ( upon having successfully met the condition(s) -- in your case being the first client to have asked for / to have completed a .connect() -- another, working, port is being used privately for a "transport" phase ( and in your case, the original port is being closed ).
This way your application does not devastate either local-side, or the remote-side resources as aPortToKnockAt provides means to protect soliton-archetype only handshaking and forthcoming attempts to knock there will find just a .close()-ed door ( and will handle that remotely ), so a sort of a very efficient passive reject is being achieved.
We are using spring-integration for TCP communication, and see behaviour where a TcpConnectionCloseEvent is received just before a message on that connection.
This is a problem because we are using the TCP events to keep track of connections, etc. and it makes for much more complex scenarios when we need to accept messages on connections that we consider closed.
The same is the case the other way around - sometimes we receive a message for a connection that we do not yet know has been opened.
Is there any way to ensure the correct order of these events, even though they are asynchronous in nature?
(Thanks for the great answers here on stackoverflow, Gary).
Hmmm...
On the server side, the open event is published by the thread that accepts the new connection rather than the connection itself. While we could possibly do something there, it still wouldn't be foolproof when using NIO because the threading model there is much more complex and there would be no way to guarantee the order even if the connection itself published the event.
To be honest, we didn't anticipate the events would be used in this way - the primary driver (for the open events) was to allow an application to detect a new connection without the client actually sending anything (just connecting) - allowing a server-side application to accept a new connection, get a handle to the connection id so it can send a welcome message.
One workaround might be to use an event inbound channel adapter and a <delayer/> to delay the event delivery to your application (in the case of the close).
I don't really have a good solution for the late delivery of the open event; perhaps just treat an inbound message for a "new" connection as an "open" event (e.g. publish your own open event when you detect this condition on the thread that's processing the message, and ignore the "real" event).
I don't get one thing in RMI. It's a bit confusing actually.
On client side, we have the business interface (Hello.class), the client code (HelloClient.class) and the remote stub (probably Hello_stub.class) and on server side we have the server code (HelloImpl.class), the business interface (Hello.class) and the skeleton .
For Java 5 onwards, we don't create stubs but still they are c=in picture i believe.
So, how does the communication happen ?
The client calls method on Hello.class which then calls Hello_stub.class for all n/w operations. The Hello_stub.class calls the skeleton which then calls Hello.class and then calls methods on HelloImpl.class ?
I am a bit confused after reading Head first EJB :) .It would be glad if someone clarified it.
When the stub's method is called:
It gets a TCP connection to s target out of the client connection pool, or creates one if there isn't a pooled connection
Bundles up the call and the arguments into a serializable object.
Writes the object to the connection along with some other stuff like a JRMP protocol header and a remote objectID.
Reads the reply object from the connection.
Returns the connection to the pool, where it gets closed after a certain idle time.
If the reply object is an exception, throws it.
Otherwise returns the reply object as the method result.
At the server, a thread sits on the listening socket, accepting connections, creating threads, and dispatching incoming remote calls to the correct remote object via the specified object ID.
This is done via reflection. RMI skeletons haven't been used since 1998, except in the case of stubs you deliberately generate with rmic -v1.1, but the principle is the same either way.
I have a multi-process TCPServer which creates (by fork() on linux) one process (child) per client's request, and in the meanwhile it is listening other connection's request. So I have a 1 to 1 mapping between client and server.
Suppose that one client crashes...is it possible to reconnect it to the same child server process?In other terms..is it possible to restore a pre-exhistent connection which is failed or the attempts to reconnect create a new connection (and then a new child server process)? thank you...
Without some knowledge (by the forker) of the interior session-related details (of the forkee), you have to make assumptions about external details being adequate to determine which remote connections get re-associated with which local connection end-points.
You could change the way things work in your application, though. Oracle SQL*Net does this on some platforms (due to platform limitations).
The initial connection to the TCPServer causes a fork and then opens up a new listening socket, sends back a redirection instruction to connect to the new listening socket & identifying details (to avoid someone else connecting and impersonating the original connector). The client then connects to the new socket, and uses this socket to do any re-connections upon disconnects before their time.
I have done something very similar to this in .NET platform. If you have something which is unique for every connection (for example IMEI of the connecting device this can be done).You should have some global two-dimensional array variable with combination of ProcessID and IMEI. So when device is disconnected and then the device reconnects you only search in this array for this IMEI and you have the process for this device. You should be very carefull with this global variable.
Edited:
I gave an example of some unique identifier. In my case that was the IMEI of the devices. In your case that could be something else which you know it is unique.
I had to do this because I had very big problem with devices breaking up the connection. Every new device was new connection so afterward I ended up with very big CPU usage.
Maybe you can refer https://eternalterminal.dev/howitworks/. Both the client and the server need change.