Tag Info

New answers tagged

1

The easiest approach if you can accept the drawbacks is to have tomcat as a passive server such that it never contacts the server app. All data flows the other way by periodicly sending heart beats to tomcat and retrieve the json data you mentioned. The drawbacks is that it will (only) be eventual consistent so you will have to accept a small time delay. ...


0

Edit: I see that the post is old, however I'll toss the answer up anyways. In my humble opinion, I think the proper way would be to design this in three pieces. Server.cs - the logic that behind the server Client.cs - the logic that behind the client Your UI. You would only need two threads, one that the UI runs on which you don't have to worry about ...


1

The blocking read is antiquated; modern servers use a asynchronous read where the program passes a buffer to the API where the data should end up in and gets a token representing the operation. No extra threads necessary. Several token can be waited for at the same time so the server can dispatch a several reads and writes and then wait on all tokens until ...


2

I interpret your question in a way that you refer to TCP/IP sockets. With UDP/IP sockets it is different. Two scenarios: Scenario 1: 1. bind 2. connect 3. listen Result: You cannot listen at a connected socket. >>> import socket >>> s = socket.socket() >>> s.bind(('', 0)) >>> s.send(b'a') Traceback (most recent call ...


0

Having provided firewall and VPN support for a couple of years now, I can tell you with confidence that applications which keep ports open for an extended period of time are not stable from both the local server perspective and the network point of entry perspective. It can also be a security risk (if that is a consideration in your case). Leaving a ...



Top 50 recent answers are included