Newbie TCP/UDP question... - Programmer

This is a discussion on Newbie TCP/UDP question... - Programmer ; Let's see if some other poor souls out there are writing code today.... I'm in the midst of my first development assignment where I have to use sockets. Now I've used TCP sockets lightly, and I understand the basic dataflow ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Newbie TCP/UDP question...

  1. Newbie TCP/UDP question...

    Let's see if some other poor souls out there are writing code
    today....

    I'm in the midst of my first development assignment where I have to
    use sockets. Now I've used TCP sockets lightly, and I understand the
    basic dataflow concept - command/response, etc. My application is
    also going to make use of UDP (so I have been told), and I do not
    understand the dataflow model (nothing appears visually in my brain).
    I'm missing something fundamental... maybe someone can provide a
    'picture' for me.

    From the extensive reading I have been doing, the 'general'
    programming model for UDP is that it is connectionless, and the
    application receiving data had better be listening when the data is
    there, else, better luck next time. My application model is pretty
    simple - I have a box generating system status information. The
    blocks of data are relatively small, and the system has it's own
    dedicated network. This box does not have the time/resources to send
    a TCP message to the other systems interested in this data - so it
    uses UDP to just blast it out there. It expects the interested
    parties to listen.

    Now, what I cannot get in my head is the programming model required
    for the listeners. The listeners may or may not be interested in the
    UDP data (depends on what they happen to be doing). They may ignore
    as they see fit. Fuzzy picture #1 in my head seems to be a separate
    thread to establish the listener function of the UDP processing.
    Fuzzy picture #2 says to just check for data when I can get around to
    it. Make it part of the main thread. I have to be somewhat cautious,
    as my cpu budget is not infinite.

    For #1, my thread can wait for data. The main thread can then simply
    decide whether or not to discard it. #2 seems somewhat simpler. It
    just lets the data dribble all over the 'ground' - overflow?

    Any feedback is MOST appreciated. I've got a number of books in front
    of me, but they are too low level and do not address the application
    issues.

  2. Re: Newbie TCP/UDP question...

    cgilley@bravesw.com (Charles Gilley) wrote in message news:...
    > Let's see if some other poor souls out there are writing code
    > today....
    >
    > I'm in the midst of my first development assignment where I have to
    > use sockets. Now I've used TCP sockets lightly, and I understand the
    > basic dataflow concept - command/response, etc. My application is
    > also going to make use of UDP (so I have been told), and I do not
    > understand the dataflow model (nothing appears visually in my brain).
    > I'm missing something fundamental... maybe someone can provide a
    > 'picture' for me.
    >
    > From the extensive reading I have been doing, the 'general'
    > programming model for UDP is that it is connectionless, and the
    > application receiving data had better be listening when the data is
    > there, else, better luck next time. My application model is pretty
    > simple - I have a box generating system status information. The
    > blocks of data are relatively small, and the system has it's own
    > dedicated network. This box does not have the time/resources to send
    > a TCP message to the other systems interested in this data - so it
    > uses UDP to just blast it out there. It expects the interested
    > parties to listen.
    >
    > Now, what I cannot get in my head is the programming model required
    > for the listeners. The listeners may or may not be interested in the
    > UDP data (depends on what they happen to be doing). They may ignore
    > as they see fit. Fuzzy picture #1 in my head seems to be a separate
    > thread to establish the listener function of the UDP processing.
    > Fuzzy picture #2 says to just check for data when I can get around to
    > it. Make it part of the main thread. I have to be somewhat cautious,
    > as my cpu budget is not infinite.
    >
    > For #1, my thread can wait for data. The main thread can then simply
    > decide whether or not to discard it. #2 seems somewhat simpler. It
    > just lets the data dribble all over the 'ground' - overflow?
    >
    > Any feedback is MOST appreciated. I've got a number of books in front
    > of me, but they are too low level and do not address the application
    > issues.


    Charles,

    I think option 1 is your best bet. Receive all the data that you can,
    and then determine if you need it or not. Otherwise you don't know
    what you missed, or if you missed anything at all. What's the point of
    broadcasting data if none of your listeners actually make it a
    priority to read it?

    You mentioned that there are cases in which the Listening Parties may
    not need the data. In this case, you could have your main thread
    create the data receipt thread only when it is ready for data. In this
    scenario your application doesn't do any unnecessary processing, like
    receiving data and dropping it.

    Hope this helps!
    --Trudy

+ Reply to Thread