1 2 3 4 Previous Next 58 Replies Latest reply: Mar 29, 2012 4:18 AM by gimbal2 Go to original post RSS
      • 30. Re: Datagram degradation
        796440
        895583 wrote:
        I know send() works like that, but what I mean is "once the code hits a lower-level call, it depends on Java to marshall the data and form the packet", so there must surely be a degree of system timing in there.
        It does it as fast as it can, subject to thread scheduling. There's no reason to believe Java would be special or insufficient in how this is handled. Again, the onus is on you to call send() at the appropriate rate, and it's on you to make sure the receiver calls receive as fast as it can, and to handle out-of-order packets and jitter properly.
        • 31. Re: Datagram degradation
          898586
          Right.That's sounding helpful indeed.

          On your point about the receiver handling as fast as it can, I believe I have that. (Well, if my loop were any smaller, it wouldn't exist). On jitter - there is none. On out-of orders - well this doesn't show up for two parties, and given that the third party's packets will be going somewhere else entirely, I can't quite get my head around that one yet.

          This leaves the send() scenario - and this I could well be doing some inadvertent goose stuffing. But would this affect the ultimate collision likelihood though?
          • 32. Re: Datagram degradation
            EJP
            I know send() works like that, but what I mean is "once the code hits a lower-level call, it depends on Java to marshall the data and form the packet", so there must surely be a degree of system timing in there.
            No there isn't. You're trying to have iit both ways here. Either 'send() works like that' or 'there must surely be a degree of system timing in there'. Not both. Java certainly does not do any timing whatsoever, either in UDP or TCP. It just calls the kernel, and the UDP stack doesn't do any timing either.
            On receive(), the timing amounts to a blocked call
            Of course. receive() isn't the problem. send() is the problem.
            so there's even greater reliance on the system to sort it all out with its clocks.
            There are no clocks associated with receiving UDP except the socket timeout. There is just data. Or not.
            I'm running a packet post-office at full capacity
            And that's the problem. Don't.
            and its maxima can't be determined by me
            Your incominng ACKs or NACKs tell you whether you're going too fast.
            - therefore I can't overload the system, even if I wanted to.
            I dont understand that inference but it is certainly fallacious. You can certainly send UDP too fast, and that can overload the network.
            • 33. Re: Datagram degradation
              898586
              EJP -

              by 'timings' and other references to clocks etc., I don't mean explicit executive powers over these - I mean generalised sub-cutaneous routines, on which my code effectively "has to wait". (I am a little bit further along the curve than my misapplied language perhaps implies).
              • 34. Re: Datagram degradation
                898586
                Addendum :
                ( send() is out of my control - I can call it, but I can't tell it how fast to execute ).

                Thanks.
                • 35. Re: Datagram degradation
                  796440
                  895583 wrote:
                  On your point about the receiver handling as fast as it can, I believe I have that.
                  You can either go with that assumption, and look somewhere else, or you can question that assumption.
                  On jitter - there is none.
                  That sounds... questionable. How are you determining this?
                  On out-of orders - well this doesn't show up for two parties,
                  You've measured this? You're looking at sequence numbers and never once seeing packet N arrive before packet N - 1?
                  and given that the third party's packets will be going somewhere else entirely, I can't quite get my head around that one yet.
                  What does the third party have to do with it? Any time you send more than one packet from point A to point B, the packets can arrive in the wrong order.
                  This leaves the send() scenario - and this I could well be doing some inadvertent goose stuffing. But would this affect the ultimate collision likelihood though?
                  If you're sending way too fast, yes. I think VOIP packets are typically sent every 2-20 ms, depending on the codec. If your sender is just doing sampel/send/sample/send as fast as it can, then you could very well be "talking over yourself", as it were. Although if this were the case, it sounds a bit suspicious to me that 3 peers vs. 2 would be the tipping point. I don't know why 2 wouldn't also cause it, or why not 5 or 10. Still, it could be that 2 is just under the limit and 3 is just over.

                  Or maybe with 2 peers you're talking in turns, and with 3 you have 2 talking at once? Or maybe your code introduces some kind of feedback loop when you add the 3rd peer?
                  • 36. Re: Datagram degradation
                    796440
                    895583 wrote:
                    Addendum :
                    ( send() is out of my control - I can call it, but I can't tell it how fast to execute ).
                    You don't need to tell it how fast to execute. You just need to be calling it often enough but not too often.
                    • 37. Re: Datagram degradation
                      898586
                      Right. All very useful info, thnx.
                      depending on the codec
                      I'm not using one.
                      • 38. Re: Datagram degradation
                        EJP
                        by 'timings' and other references to clocks etc., I don't mean explicit executive powers over these - I mean generalised sub-cutaneous routines
                        I have no idea what you mean by this.
                        (I am a little bit further along the curve than my misapplied language perhaps implies)
                        With respect, when you ask how there can be collisions 'when every client has a separate socket'; find it 'interesting' that I 'made no differentiation between client and server in terms of dropped packets'; ask whether collisions only happen to UDP packets; ask what I mean by 'the same network'; claim 'I can't overload the system, even if I wanted to'; say '"once the code hits a lower-level call, it depends on Java to marshall the data and form the packet", so there must surely be a degree of system timing in there'; claim there are clocks associated with receive(), etc. etc., it isn't 'misapplied language' at all. It is lack of basic knowledge.
                        ( send() is out of my control - I can call it, but I can't tell it how fast to execute )
                        Or this. It executes as fast as it can. I keep saying that. The issue is how frequently you call it. Any clocks, 'executive powers', 'subcutaneous routines', etc., must be in your own code.
                        depending on the codec
                        I'm not using one.
                        So how are you turning voice into data?
                        • 39. Re: Datagram degradation
                          ++sja
                          Your computers are likely connected to a router. The router reserves some amount of buffer space for each computer that is plugged into it. If you send the router a burst of packets, you can overflow the buffer memory. Or if you are talking over an ADSL/cable/etc modem you can overflow its buffers too.

                          The receiving computer also has buffer space that you can overflow if the receiving application does not manage to handle the incoming packets fast enough.

                          If you have two computers that send stuff as fast as they can, they just might be able to handle the incoming data. But when you add a third one, you could well get erratic behaviour when two computers randomly gang up on the third one and overflow the poor guy's input buffer.

                          TCP has congestion controls that attempt to discover how fast the overall connection is, and retransmits if the estimate fails. UDP has no such thing. If you use UDP you'll need to think how much stuff you can send without overflowing some component of your network.

                          (Aside: I think actual packet collisions are rare nowadays. Back in the old days Ethernet used to be coaxial cable, and had real collisions, when several computers could start sending bits on the same physical cable simultaneously, and the electric signal would get all garbled. Now it's all newfangled full duplex, with separate wires for each direction. Maybe if you use a wireless network you could still have genuine old-fashioned collisions.)
                          • 40. Re: Datagram degradation
                            gimbal2
                            Its a nice summary that includes the world "newfangled" (absolutely love that word), but I wonder if you actually add anything of value to this thread that hasn't been already said in one way or another.
                            • 41. Re: Datagram degradation
                              898586
                              So how are you turning voice into data?
                              Ehhhh?
                              • 42. Re: Datagram degradation
                                796440
                                895583 wrote:
                                So how are you turning voice into data?
                                Ehhhh?
                                If you're not using a codec, then how are you turning your audio signal into bytes and vice versa?

                                http://en.wikipedia.org/wiki/Codec
                                http://en.wikipedia.org/wiki/Audio_codec
                                http://en.wikipedia.org/wiki/List_of_codecs#Voice
                                • 43. Re: Datagram degradation
                                  EJP
                                  So how are you turning voice into data?
                                  Ehhhh?
                                  Is that more 'misapplied language'? Or is the truth of this that you just don't know what a codec is?

                                  I may be old fashioned but when I speak on a phone I do not emit byte arrays.
                                  • 44. Re: Datagram degradation
                                    796440
                                    EJP wrote:
                                    I may be old fashioned but when I speak on a phone I do not emit byte arrays.
                                    Luddite.