I am using the Whole Message Delivery functionality of Jetty Websockets.
In such a case, Joakime says that Websocket messages are guaranteed to be delivered in order.
I am going to go on a limb and assume that all Websocket event-handling methods will be invoked by the same thread.
Now, say an external timer expires and I need to send a message over the websocket. The timer runs in one thread and the Websocket events run on a different thread.
Do I need to make my Websocket event handlers thread-safe (seeing as their state will be accessed by the timer and Websocket thread)? Or is there a way for the timer thread to pass a task to the Websocket thread to execute?
The Jetty WebSocket API (Native or javax.websocket) doesn't care about the thread safeness of the local WebSocket End Point.
It will deliver the next message when it arrives.
Note: you can control suspend / resume of the read thread with the Jetty Native WebSocket API.
Related
I am trying to implement SCTP support for an existing delphi application in Linux platform. I am using lksctp to support SCTP protocol. Also I am trying to use epoll(level triggered mode with EPOLLONESHOT flag) for event notification on the sockets. I am facing issue with the event handling and I am not getting where I am doing wrong or what I missed. Below is my scenario, It would be great if someone could help here to understand what is going wrong.
Currently from the server side I could see the server is reading(using sctp_recvmsg function) and processing same data repeatedly. Unfortunalely I could not post the code as the application code is very big.
Belows is the process flow of the application from the server side.
When the application starts epoll instance is created and the main thread creates a new thread which waits on the epoll handle for any network events(like EPOLLIN, EPOLLOUT etc..). The thread function waits on the epoll instance using epoll_wait() and once any event is notified by epoll_wait(), then the event type (like EPOLLIN, EPOLLOUT etc..) is recorded in a structure along with the socket descriptor and is pushed into a queue. Then the main application loop retrieves the structure one by one from the queue and performs the processing(sctp_send() or sctp_recvmsg() etc..) accordingly.
Down the line, the application creates a listening socket and adds(with EPOLLONESHOT flag enabled) this socket descriptor to the epoll handle created in step#1. Also the application starts listening on this listening socket.
Once the server receives a connection request from the client, the epoll handle signals the EPOLLIN event and the thread function pushes a structure with the event type and socket FD to the queue.
The main application loop retrieves the structure (with event details pushed to the queue in step#3) and processes the above connection request and it accepts the connection. At this point(ie after accepting connection) the listening socket is again re-armed for event notification using epol_ctl() and 'EPOLL_CTL_MOD'(This was done because of the EPOLLONESHOT used).
The newly accepted socket also now added(with EPOLLONESHOT flag) to the epoll handle created in step#1 for event monitoring.
Now the server receives a message ('UP' message) from the client on the newly accepted socket and epoll signals the EPOLLIN event.And the thread function pushes a structure with the event type and socket FD to the queue.
The main application loop retrieves the structure from the queue and does the processing, that means the Server now reads the 'UP' message from the newly accepted socket using sctp_recvmsg(). Immediately after this point the socket is re-armed for event notification using epol_ctl() and 'EPOLL_CTL_MOD'(This was done because of the EPOLLONESHOT used).
In response to the 'UP' message received in step#7 server sends 'UP_ACK' and 'NTFY' message back to client.
Client receives the 'UP_ACK' and 'NTFY' message from server and send back 'ACTIVE' message to server.
Now in the server side the epoll handle signals an EPOLLIN event and the server again tries to read the message using sctp_recvmsg(), now when the servers reads the message it is getting the same initial 'UP' message received in step#6 rather than the 'ACTIVE' message in step#9. Now the server agains sends 'UP_ACK' and 'NTFY' back to client and this goes on.
I checked from client side and i see it send the 'UP' message only one time.
Can someone give a hint on why the server is receiving the 'UP' message multiple times?
Once the server calls the first 'sctp_recvmsg()' for the 'UP' message shouldn't it remove the message from socket?.
Also can someone suggest the positions where I do the re-arming of sockets for event notification is correct? Or should I be doing it in the thread function where it is waiting for events using epoll_wait() ?
I have a server where I handle multiple clients. Each client that connects to it is serviced in its own thread. Now, if any errors occur on the server side, I want to exit that thread by calling pthread_exit, and terminate the client that was being serviced by that thread. However; when I try to do so, my client is hanging. Also, this causes other clients that are in different threads to hang as well. I called pthread_exit in a random spot to test it...
Most likely the problem is that you are not calling close(newsockfd) before you call pthread_exit(). If so, then your server-thread goes away, but the socket that it was using to communicate with the client remains open, even though the server is no longer doing anything with it. Then the client's outgoing TCP buffer fills up, and the client waits indefinitely for the server to recv() more data from the socket, which never happens.
As the documents say, ZMQ sockets are not thread-safe. So I assume the answer to the title is 'No'.
Still, I can't figure out how to implement a non-blocking request-reply pattern using ZMQ:
Specifically, the client has a main thread which goes on about its business processing messages from a (thread-safe) message queue. The messages come from various sources, such as network, timers, I/O etc.
Occasionally the main thread wishes to send a request to a remote server, but it does not want to wait for a response (which may take a while to arrive).
Normally, I would use two threads:
The main message-processing loop thread. This will send() request on the REQ/REP socket
An auxiliary listener thread which will wait for the response from the server. This will use a blocking recv() on the socket, and push the responses to the main thread's queue.
How would I achieve this using ZeroMQ? Should the auxilary thread open an inproc socket and listen to messages from the main thread?
Actually, single thread is enough. Just send request to the server and poll messages with zmq_poll().
This model is fine if one request at a time is suffucient. If you need so send multiple requests and read replies asynchronously, use DEALER socket instead of REQ. Just send some requestId as the first frame, then add empty delimiter frame, then send actual request.
Chapter 3 of the guide has more details about REQ/REP message envelopes: http://zguide.zeromq.org/php:chapter3
Please let me know if this isn't clear enough, I will probably extend my answer with few code samples.
Is it possible to create an event object that becomes signalled when GUI message(s) is/are available, like one can create event objects that signal the presence of data on a socket for instance? The idea would be to use a WaitMultipleEvents for either something happening on the GUI or a request arriving on a TCP/IP socket.
I'd delegate the whole client/server comm stuff to a background thread if this weren't a QuickTime app (QuickTime is rather quirky where multithreading is concerned, on win32 at least).
BTW, can one do things like moving/resizing/renaming windows created on another thread, using the dedicated functions - or would that require posting messages explicitly?
There's no waitable object for messages in your queue, but there is a wait function that will wait for a waitable object or a message in your queue. See MsgWaitForMultipleObjects.
There is no such event to signal that a Windows message is available. The solution is to get socket notifications in the form of a Windows message instead of an event. WSAAsyncSelect configures this mode in the socket. This let you use your message loop to get both GUI messages and socket notifications, all in one thread.
Thanks for your answers. Indeed, I was reminded elsewhere of MsgWaitForMultipleObjects, and use that (code extract:)
I have a Delphi 6 application that uses the ICS component suite to do socket communications. I have my own server socket VCL component that creates client TWSocket sockets when a new session becomes available. The client sockets I create do have the Multithreaded property set to TRUE, but all that does is changes the way the client socket handles socket messages to a manner that is safe from a background thread (non-main VCL thread). TWSocket does not spawn a thread to handle socket data traffic, which is what I need.
I need to have the receive calls occur off the main VCL thread, the main user interface thread, because the incoming data to the client socket is audio data that needs to be processed rapidly, in 50-100 milliseconds or less. In other words, one hiccup on the main VCL thread and the audio stream is disrupted. This is why I want to push the OnDataAvailable() event that fires whenever incoming data is available on to a high priority background thread. In other words, I want to force the message processing loop belonging to the client TWSocket object to a background thread.
I believe I can do this by creating the client socket via a background thread, but I'm hoping to avoid that since currently I use a VCL component I made that acts as a socket server. This is the entity that Accepts the incoming connection and spawns the client sockets. The socket server is created on the main VCL thread.
Therefore my question is, is there a (relatively) easy way to create the client sockets so they use an existing background thread to do their socket processing, especially the FD_RECV message handling? If not an existing background thread, then I will create one for each client socket I create, but I need to know how to make sure the new TWSocket object uses that background thread when it runs its message loop that processes socket messages, so how would I do that?
For other ICS/TWSocket users out there, the solution is in the ICS ThrdSrv demonstration project that comes with the package. Take a close look at that project, especially its use of the ThreadAttach() and ThreadDetach() methods. That sample project shows how to create client sockets that have message pumps that run in the context of a worker thread.