Re: xinetd UDP vs. TCP Output

2011-02-27 Thread Hal Vaughan
Short answer:

It's not possible.

Long answer:

After the research it took me, I'm just too damned lazy to write it up.  Just 
trust me, can't be done.



Hal

On Feb 24, 2011, at 3:49 AM, Hal Vaughan wrote:

 I'm using a small program that's started by xinetd.  The incoming signal to 
 it would be a broadcast signal, which means it has to be UDP.
 
 I wrote two versions of the test program, one in Perl and one as a bash 
 script and both ran into the same problem.
 
 They worked fine when I first set them up and set up the service in xinetd as 
 using TCP.  Then I changed the service to UDP and made the appropriate 
 changes to my programs.
 
 They still logged everything, they still received incoming messages from the 
 other test programs that were communicating to them (either directly or 
 through a broadcast), but they did NOT send any data back.  I checked it this 
 with Wireshark.  The incoming data showed up, but the data these programs 
 were supposed to send back didn't even go out over the LAN.
 
 The programs ran and exited properly, but the output to the network never 
 showed up.
 
 While I don't know but so much about networking, I know TCP and UDP sockets 
 are notably different.  I can't find anything in the documentation that 
 indicates that for a program using UDP sockets, that it has to use something 
 other than STDIN and STDOUT.  I even found sources that say you SHOULD still 
 be using STDIN and STDOUT for programs using UDP through xinetd.
 
 I don't consider this just a programming question, since it's the same in 
 both languages.  I strongly suspect there's a different way to handle the 
 output that's supposed to go back over the network for UDP (vs. TCP).
 
 Any ideas on what might be needed?
 
 
 Thank you!
 
 
 Hal
 
 -- 
 To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: 
 http://lists.debian.org/088447f7-8cad-47ad-ba76-7d3346c7a...@halblog.com
 
 


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/b53fd3ac-a847-42eb-8126-43c92b955...@halblog.com



xinetd UDP vs. TCP Output

2011-02-24 Thread Hal Vaughan
I'm using a small program that's started by xinetd.  The incoming signal to it 
would be a broadcast signal, which means it has to be UDP.

I wrote two versions of the test program, one in Perl and one as a bash script 
and both ran into the same problem.

They worked fine when I first set them up and set up the service in xinetd as 
using TCP.  Then I changed the service to UDP and made the appropriate changes 
to my programs.

They still logged everything, they still received incoming messages from the 
other test programs that were communicating to them (either directly or through 
a broadcast), but they did NOT send any data back.  I checked it this with 
Wireshark.  The incoming data showed up, but the data these programs were 
supposed to send back didn't even go out over the LAN.

The programs ran and exited properly, but the output to the network never 
showed up.

While I don't know but so much about networking, I know TCP and UDP sockets are 
notably different.  I can't find anything in the documentation that indicates 
that for a program using UDP sockets, that it has to use something other than 
STDIN and STDOUT.  I even found sources that say you SHOULD still be using 
STDIN and STDOUT for programs using UDP through xinetd.

I don't consider this just a programming question, since it's the same in both 
languages.  I strongly suspect there's a different way to handle the output 
that's supposed to go back over the network for UDP (vs. TCP).

Any ideas on what might be needed?


Thank you!


Hal

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/088447f7-8cad-47ad-ba76-7d3346c7a...@halblog.com