User Tag List

Page 4 of 6 FirstFirst ... 2 3 4 5 6 LastLast
Results 31 to 40 of 59

Thread: Binary messages

  1. #31
    Clicker Multimedia Fusion 2 Developer

    Join Date
    Jun 2006
    Location
    Darlington, UK
    Posts
    3,298
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Stack messages

    Basically TCP is automatically fragmented and reassembled to fit the MTU, so the max stack size is as large as it can be. UDP is just dropped if it exceeds the MTU, so you have to keep small.

  2. #32
    Clicker Fusion 2.5 MacFusion 2.5 DeveloperAndroid Export ModuleHTML5 Export ModuleiOS Export ModuleSWF Export ModuleXNA Export ModuleUnicode Add-on
    Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Fusion 2.5+ DLC (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)Firefly 3D Module (Steam)
    Phi's Avatar
    Join Date
    Jan 2010
    Location
    England
    Posts
    1,896
    Mentioned
    21 Post(s)
    Tagged
    0 Thread(s)

    Re: Stack messages

    Indeed, the program that sends files via UDP works faster than TCP and is just as guaranteed.

    I did some speed tests. UDP works 2 seconds faster than TCP per megabyte, so although I wouldn't recommend it for game applications, in the filesharer it's a good idea.

  3. #33
    Clicker Fusion 2.5 DeveloperSWF Export Module

    Join Date
    Jun 2006
    Location
    Turku, Finland
    Posts
    1,023
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Stack messages

    Seriously, I would trust the person who has made the Lacewing extensions instead of making unaccurate tests. TCP is slow because it is accurate. If you make UDP as accurate as TCP is with checks, it will be at least as slow. Why would TCP otherwise exist?

  4. #34
    Clicker Multimedia Fusion 2 Developer

    Join Date
    Jun 2006
    Location
    Darlington, UK
    Posts
    3,298
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Stack messages

    A UDP packet is dropped (never received) in the following situations:
    Random corruption of packet header
    Encountering an MTU smaller than the packet
    Full buffer on a router
    On a whim

    A UDP packet will corrupt your transfer in the following situations:
    All the above
    Random corruption of packet body
    Arriving out-of order
    Arriving twice

    In practice, the above are very rare, except over wifi or a dodgy network cable.

    I don't know how much of that Lacewing compensates for, if any. Regardless, it's a bad idea to send one piece of data (e.g. a file) in multiple UDP packets.

  5. #35
    Clicker Multimedia Fusion 2 DeveloperSWF Export Module

    Join Date
    Jun 2006
    Posts
    6,773
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    Re: Stack messages

    Quote Originally Posted by Dynasoft
    A UDP packet will corrupt your transfer in the following situations:
    [..]
    Random corruption of packet body
    UDP uses a checksum - I'm pretty sure the packets can't get corrupted (although I guess there could be a freak checksum collision, it's not very likely).

  6. #36
    Clicker Fusion 2.5 MacFusion 2.5 DeveloperAndroid Export ModuleHTML5 Export ModuleiOS Export ModuleSWF Export ModuleXNA Export ModuleUnicode Add-on
    Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Fusion 2.5+ DLC (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)Firefly 3D Module (Steam)
    Phi's Avatar
    Join Date
    Jan 2010
    Location
    England
    Posts
    1,896
    Mentioned
    21 Post(s)
    Tagged
    0 Thread(s)

    Re: Stack messages

    Quote Originally Posted by Ravenius
    Seriously, I would trust the person who has made the Lacewing extensions instead of making unaccurate tests. TCP is slow because it is accurate. If you make UDP as accurate as TCP is with checks, it will be at least as slow. Why would TCP otherwise exist?
    Hmm. I don't think the tests were unaccurate. TCP exists so it can be used as a reliable transfer which will suit almost any application.
    Quote Originally Posted by Dynasoft
    Basically TCP is automatically fragmented and reassembled to fit the MTU, so the max stack size is as large as it can be. UDP is just dropped if it exceeds the MTU, so you have to keep small.
    I use UDP in this way for the simple reason which is speed. In a multiplayer game I would use UDP for position sending only, and I wouldn't even consider using UDP for anything else. Because I am creating a filesharing program, I use it. The size of the file, and the size of the peer's stacks, etc, are already known as the sender will inform the receiver. In a game, you would have to inform (via TCP) the other users what size UDP messages they should receive, for each packet in this system, making it useless.
    Finally, in my filesharing app, no UDP packets will be corrupt, if they are missed they will be requested again (after the main loop), and if they are received twice, they will be saved to the same memory address and the second one will overwrite the first, giving the same output.
    I will do some more TCP vs UDP tests to make sure of my findings, but I'm sticking to what I used to have - for each megabyte, UDP takes 58 seconds to receive, and TCP takes 60 seconds.

  7. #37
    Clicker Fusion 2.5 Developer

    Join Date
    Nov 2008
    Posts
    299
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Stack messages

    Quote Originally Posted by Jamie
    Quote Originally Posted by Dynasoft
    A UDP packet will corrupt your transfer in the following situations:
    [..]
    Random corruption of packet body
    UDP uses a checksum - I'm pretty sure the packets can't get corrupted (although I guess there could be a freak checksum collision, it's not very likely).
    Checksums aren't reliable (they just "check the sum"). They aren't a hash, either.

    And while it is not likely to happen for small packages, imagine transferring megabytes and megabytes of data - more than once.

    Unless you implement your own error-checking mechanism (CRC is a good bet), you'll eventually run into corruptions. And if you implement an error checking mechanism, then why bother with UDP?

  8. #38
    Clicker Multimedia Fusion 2 Developer

    Join Date
    Jun 2006
    Location
    Darlington, UK
    Posts
    3,298
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Stack messages

    UDP doesn't checksum the packet body, only (optionally) the header (unlike TCP).

    EDIT: Seems I'm wrong about that. However, the checksum is optional.

  9. #39
    Clickteam Clickteam
    LB's Avatar
    Join Date
    Jun 2007
    Location
    Richardson, Texas, North America
    Posts
    8,937
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)

    Re: Stack messages

    I like RDP better
    Working as fast as I can on Fusion 3

  10. #40
    Clicker Multimedia Fusion 2

    Join Date
    Jun 2009
    Location
    Earth
    Posts
    54
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Stack messages

    Could somebody upload an example of how to send files? Everything I've tried just gets files of 0 bytes.

Page 4 of 6 FirstFirst ... 2 3 4 5 6 LastLast

Similar Threads

  1. RPG-like Text Messages
    By Corlen in forum Multimedia Fusion 2 - Technical Support
    Replies: 0
    Last Post: 9th June 2012, 03:18 PM
  2. Help Messages
    By Pixzel in forum Multimedia Fusion 2 - Technical Support
    Replies: 1
    Last Post: 25th March 2011, 10:43 PM
  3. Sphax Messages Box
    By Jeff in forum Released Extensions
    Replies: 3
    Last Post: 9th April 2009, 10:14 AM
  4. Encrypting messages in Moo
    By Plooscva in forum Multimedia Fusion 2 - Technical Support
    Replies: 6
    Last Post: 24th February 2007, 11:49 AM
  5. Messages Box object - Bug
    By Gustav in forum File Archive
    Replies: 9
    Last Post: 26th November 2006, 03:29 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •