Hi all Not to answer my own question, but it seems like "open/binary/direct" now keep the TCP and UDP payloads the same size. What is the default settings if you specify just "open"?
Leon -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Leon Meyer Sent: Thursday, November 19, 2009 7:42 PM To: [email protected] Subject: [REBOL] Re: UDP Multicast to TCP Hi Although the TCPtoMulticast and MulticastToUDP applications are working, we have picked up an small problem. The Payload size of the UDP output packets after the conversion does not seem to be exactly the same as the incoming TCP Payload size (always a couple of bytes extra). The larger the incoming TCP payload size, the more bytes seem to be added to the output UDP payload. We have confirmed this using Windump (windows version of tcpdump). For example, a 16 bytes TCP payload becomes a 17 bytes UDP payload A 771 bytes payload becomes a 778 UDP payload. Does anyone have any idea what could be causing the additional bytes in the UDP payload? Here is the TCPtoUDP script: REBOL[Title: "Port 4550"] listen: open/no-wait tcp://:4550 waitports: [listen] odata: open udp://239.2.0.80:6550 ; udp broadcast port set-modes odata [multicast-ttl: 10] set-modes odata [multicast-interface: 192.168.20.23] forever [ port: wait waitports either same? port listen [ active-port: first listen append waitports active-port ] [ incoming-from-remote: copy port either incoming-from-remote [ insert odata incoming-from-remote ;print incoming-from-remote ] [ remove find waitports port close port ] ] ] Thank you Leon PS - I have removed the "read requests" from my email now- sorry if it caused any problems yesterday. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Gabriele Santilli Sent: Wednesday, November 18, 2009 12:50 PM To: [email protected] Subject: [REBOL] Re: UDP Multicast to TCP On Wed, Nov 18, 2009 at 11:42 AM, Petr Krenzelok <[email protected]> wrote: > I hope I am not wrong here, but you should know, that in R2, you > basically can work in two modes - blocking (synchronous), and non > blocking. When you open your port without /no-wait refinement, then > 'copy action on port blocks. It is your case, as you issue "copy > multicast", where multicast is opened in blocking mode. In this mode, > copy waits for other side to close the connection. That might be the > reason why your code "halts". Try simple example: Mmm, Petr, actually, he's only copying on the UDP port after a wait, so I don't think this would be a problem. Besides, it seems to me that /no-wait does not work on UDP listen ports... > Console1: > --------- > server: open tcp://:9005 Your assumption that UDP behaves just like TCP is so very wrong. ;) Regards, Gabriele. -- To unsubscribe from the list, just send an email to lists at rebol.com with unsubscribe as the subject. -- To unsubscribe from the list, just send an email to lists at rebol.com with unsubscribe as the subject. -- To unsubscribe from the list, just send an email to lists at rebol.com with unsubscribe as the subject.
