in reply to Re^6: UDP connection
in thread UDP connection
Can you not see, from your own posting, that there are four pairs of ports, and each pair has to communicate in both directions?No.
I've listed the 8 data streams I've seen described by the OP. They use ports 8020, 8019, 8008, 8003 to send from, and ports 53036, 53037, 53038, 53039 to listen to. I haven't seen the OP describe traffic originating from ports 53036, 53037, 53038, 53039.
But whether or not there's bidirectional UPD traffic, that's irrelevant. I still don't see 2 processes trying to use the same port. Can you point out a port, and the two processes that need to access it?
It is implied by the OPs description.Why?
The pre-existing server might be,Most services restrict UDP packets to be at most 512 bytes. But even if they don't, UDP packets are restricted to be at most 65535 bytes (as the length field of the header is 2 bytes large), leaving slightly less for the payload. I just haven't assumed the OP runs hardware that needs more than 10 seconds to copy 65535 bytes from the IP stack to the process' memory.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^8: UDP connection
by BrowserUk (Patriarch) on May 04, 2012 at 01:41 UTC | |
I haven't seen the OP describe traffic originating from ports 53036, 53037, 53038, 53039. Geez Louise. Re-read the OPs post but concentrate on a single pair of ports:
Graphically:
4 ports at the server, 4 ports at the client; 4 bi-directional conversations. There is no ambiguity. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [d/l] |
by JavaFan (Canon) on May 04, 2012 at 11:24 UTC | |
However, there is no problem. Here are a sample server and client that do bidirection communication over 4 socket pairs. The server waits for an initial heartbeat from the client, then starts sending data, and it will stop sending data if it hasn't seen a heartbeat for 10 seconds. There's of course lots of room for improvement, but it does show bidirectional communication is not a problem. First, the server: And the client:
| [reply] [d/l] [select] |
by BrowserUk (Patriarch) on May 04, 2012 at 21:03 UTC | |
You are correct. I must have misread the numbers. It happens. Thank you for acknowledging it. However, there is no problem. Here are a sample server and client that do bidirection communication over 4 socket pairs. Hm. There are still problems you are not dealing with. I'm not talk ing about error handling or niceties here. The significance of those (perhaps apparently small) differences, is that your client treats all inbound communications as data. The OP cannot do this as he has also to distinguish between the heartbeat response and the actual data. The single byte packet size of the response should make that easy... except when you take the uncertain timing of the availability of the hexdump data into consideration. Here is the black hole in the timing scenario I was trying resolve with the OP, which your client does not -- and (I believe) as written, cannot -- resolve:
The hexdump doesn't have to be large, a single packet coming available (at exactly the wrong time) will trigger the problem. The client is expecting a single byte response. The server hasn't seen the heartbeat, so it isn't going to send it until (at least) after it finishes sending the current packet. If, after sending the heartbeat, the client went into a read state for the single byte response, it will get the first byte of the data packet, and the rest will be discarded. This is the exact scenario that the OP described in his first post. Using blocking reads -- as would normally be used in conjunction with threads as indicated by the OP -- the client cannot be in a read state in anticipation of the arrival of a data packet that could come at any time; and also send a regular heartbeat, because you cannot send() via socket, if that socket is currently in a recv() state. (At the same end!) Using select obviates that, by avoiding entering the read state until it knows (by polling) that data is ready to be read. But that alone does not completely close the window for failure. If the 10 second timeout at the server occurs exactly whilst the client is in the process of receiving the latest packet -- and is therefore unable to transmit its next heartbeat -- the server will (may) conclude that the client has 'gone away' and discard (fail to send) any subsequent data until the client re-heartbeats. And that leads to data loss, which the OP explicitly denounced. Whilst the window for such a failure is small; such are the nature of communications protocol failures. The usual solution(s) to this problem include:
And it was these details I was trying to establish with the OP before he got scared away by our ...um... discussion. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [d/l] |
by JavaFan (Canon) on May 04, 2012 at 22:11 UTC | |
by BrowserUk (Patriarch) on May 04, 2012 at 22:56 UTC | |
|