Signal based I/O for multiple sockets - VxWorks

This is a discussion on Signal based I/O for multiple sockets - VxWorks ; I am having a UDP based application which requires to receive UDP packets every 20 ms. I am using VxWorks 6.1 running on a SBC Motorola card with intel processor. My current applicationis using Non blocking I/O multiplesing as means ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Signal based I/O for multiple sockets

  1. Signal based I/O for multiple sockets

    I am having a UDP based application which requires to receive UDP
    packets every 20 ms. I am using VxWorks 6.1 running on a SBC Motorola
    card with intel processor. My current applicationis using Non blocking
    I/O multiplesing as means of receive packets from UDP socket. I am
    ruinnign multiple UDP sessions around 35. I observed that by using
    Noblocking I/O multiplexing CPU utilisation for the task which is
    handling UDP packets is very high and is posing perfromacne and
    sacalability bottlenecks.

    As means of improving performacnce I am considering a design where
    I can receive I/O notification for each socket from Kernel. Once I
    receive this notification I read the packet and despatch it to
    application and prepare my self to receive the packet again for each
    socket I received data on. From my investigation I found that there is
    POSIX Async I/O which meet my requirements. Unfortunately, async POSIX
    IO is supported for files and not scokets in VxWorks IO. I am
    exploring using Signal facility of VxWorks to achieve asynchrounous
    IO notification. I found that there is signal queuing posisble using
    sigqueue. I am wondering if I can use this facility to asynchronous IO
    notification. Is this possible ? Can this provide good performance ?
    VxWorks manul recommends signal usage only for notification or for
    error/exception handling. In this view would signal handling be useful
    for asynchroous scoket based I/O.

    Also assuming that singal based I/O for scokets can be used I
    have 2 queries as below :
    Is there a facility to get I/O data copied in appliaction passed
    buffere while installing signal handler. OR
    I use signal I/O as notification for arrival of data on a particular
    scoket and then I call recvfrom from my application to get data into
    my application buffer.

    Any thoughts, suggesion, code smplae etc ... would be of great use.
    Thanking you in anticpation.

    Mustafa


  2. Re: Signal based I/O for multiple sockets

    On Jun 8, 12:26 pm, mustak wrote:
    > I am having a UDPbasedapplication which requires to receive UDP
    > packets every 20 ms. I am using VxWorks 6.1 running on a SBC Motorola
    > card with intel processor. My current applicationis using Non blockingI/Omultiplesing as means of receive packets from UDP socket. I am
    > ruinnign multiple UDP sessions around 35. I observed that by using
    > NoblockingI/Omultiplexing CPU utilisation for the task which is
    > handling UDP packets is very high and is posing perfromacne and
    > sacalability bottlenecks.

    There is a typo here ... I am running currently 135 UDP based
    sessions sending and reciving data every 20ms. I have RTP sessions
    running on top of UDP
    >
    > As means of improving performacnce I am considering a design where
    > I can receiveI/Onotification for each socket from Kernel. Once I
    > receive this notification I read the packet and despatch it to
    > application and prepare my self to receive the packet again for each
    > socket I received data on. From my investigation I found that there is
    > POSIX AsyncI/Owhich meet my requirements. Unfortunately, async POSIX
    > IO is supported for files and not scokets in VxWorks IO. I am
    > exploring usingSignalfacility of VxWorks to achieve asynchrounous
    > IO notification. I found that there issignalqueuing posisble using
    > sigqueue. I am wondering if I can use this facility to asynchronous IO
    > notification. Is this possible ? Can this provide good performance ?
    > VxWorks manul recommendssignalusage only for notification or for
    > error/exception handling. In this view wouldsignalhandling be useful
    > for asynchroous scoketbasedI/O.
    >
    > Also assuming that singalbasedI/Ofor scokets can be used I
    > have 2 queries as below :
    > Is there a facility to getI/Odata copied in appliaction passed
    > buffere while installingsignalhandler. OR
    > I usesignalI/Oas notification for arrival of data on a particular
    > scoket and then I call recvfrom from my application to get data into
    > my application buffer.
    >
    > Any thoughts, suggesion, code smplae etc ... would be of great use.
    > Thanking you in anticpation.
    >
    > Mustafa




  3. Re: Signal based I/O for multiple sockets

    I'm actually 100% unfamiliar with vxWorks, but I'm very familiar with
    the underlying APIs that vxWorks must interface with in order to
    provide UDP networking on various Unix/Linux and Windows systems.

    On Jun 8, 12:26 pm, mustak wrote:
    > I observed that by using
    > Noblocking I/O multiplexing CPU utilisation for the task which is
    > handling UDP packets is very high and is posing perfromacne and
    > sacalability bottlenecks.


    A common mistake people make when first using non-blocking I/O is to
    constantly check their data streams (like sockets or files) for
    incoming data, without stopping to "take a breath." But if you
    inserted some kind of sleep or delay into your program to "breathe,"
    and give your CPU a rest, application performance can be greatly
    impacted, and when using a networking interface like UDP, you may even
    lose packets entirely (because your program hadn't cleared the
    incoming packet buffer when a second one arrived, since your program
    was sleeping while it happened.)

    POSIX-compliant APIs offer two facilities which in essence allow your
    program to sleep without having to worry about losing data or hurting
    performance. The first is a function called select(), and the second
    is signal-based I/O. Both are very similar internally, but which you
    choose to use will depend on how you want to structure your program.

    Based on what I've read in your email, I think it would be easiest to
    migrate to a select() paradigm, rather than one of signal-based I/O.
    Does "VxWorks" offer a method similar to POSIX "select()"? This
    function allows your program to wait until there is data available on
    various data streams (like sockets and files.) To select() you specify
    three arguments which provides the following information to select():

    - Which data streams your program is waiting for (in POSIX these are
    represented by "file descriptors," which are merely integers provided
    by the kernel APIs which refer to data streams like open files and
    sockets.)

    - Which types of operations you are waiting for (although for your
    program, the only operation you are interested in is receiving data.)

    - The maximum time you wish to wait. If this is zero, then your
    program will wait indefinitely for whatever sort of activity you
    specified in the previous two arguments. However you can specify a non-
    zero value so that your program will "wake up" from the sleep imposed
    by select() after a certain time has passed, even if no activity
    specified in your first two arguments has occurred (in your case, the
    only activity that can occur is new data arriving on UDP sockets.)
    This "timeout" argument is useful if you wish for your program to
    perform other tasks on a certain interval even in the absence of data
    stream activity. It is also useful if you wish to "give up" on waiting
    for more data, perhaps you have been disconnected from the network, or
    must check for some other error condition.

    > As means of improving performacnce I am considering a design where
    > I can receive I/O notification for each socket from Kernel.



    As I mentioned earlier, it sounds like it will probably be easier to
    migrate to a select()-driven design than a signal-driven I/O design.

    Also as mentioned earlier, the underlying functionality of using
    select() is very similar to using signal-based I/O. The difference is
    that instead of signals being received directly by your application,
    the kernel scheduler merely queues your program to return from
    sleeping once I/O is available. (In reality, as your process is in
    SLEEP state while performing select(), this is practically identical
    to being sent a SIGCONT signal, or "wake-up" signal.)

    > From my investigation I found that there is
    > POSIX Async I/O which meet my requirements. Unfortunately, async POSIX
    > IO is supported for files and not scokets in VxWorks IO.


    Are you sure about this? To me it seems much more plausible that
    "VxWorks IO" support asynchronous I/O on sockets, and does not support
    asynchronous I/O on files. The reason for this is that Windows APIs
    for asynchronous data stream access only work for sockets, not for
    files. (This information may be outdated. But it was this way around
    2002.)

    > I am
    > exploring using Signal facility of VxWorks to achieve asynchrounous
    > IO notification. I found that there is signal queuing posisble using
    > sigqueue. I am wondering if I can use this facility to asynchronous IO
    > notification. Is this possible ? Can this provide good performance ?
    > VxWorks manul recommends signal usage only for notification or for
    > error/exception handling. In this view would signal handling be useful
    > for asynchroous scoket based I/O.


    It seems very likely to me that if you queued your signals, you would
    risk missing out on UDP packets as I mentioned earlier. If you receive
    more than one packet on the same UDP socket before your program has a
    chance to empty the appropriate buffer, many kernels will simply throw
    your packet away.

    > Also assuming that singal based I/O for scokets can be used I
    > have 2 queries as below :
    > Is there a facility to get I/O data copied in appliaction passed
    > buffere while installing signal handler. OR
    > I use signal I/O as notification for arrival of data on a particular
    > scoket and then I call recvfrom from my application to get data into
    > my application buffer.


    I don't know if "VxWorks" provides this sort of functionality, but
    neither POSIX nor Windows APIs will do this for you. You must write
    your own function to copy the packet into program memory so that the
    kernel has an empty space to put the next packet that it receives on
    that socket.

    Hope I was helpful!


  4. Re: Signal based I/O for multiple sockets

    On Jun 11, 11:07 pm, Donny Viszneki wrote:
    > I'm actually 100% unfamiliar with vxWorks, but I'm very familiar with
    > the underlying APIs that vxWorks must interface with in order to
    > provide UDP networking on various Unix/Linux and Windows systems.
    >
    > On Jun 8, 12:26 pm, mustak wrote:
    >
    > > I observed that by using
    > > Noblocking I/O multiplexing CPU utilisation for the task which is
    > > handling UDP packets is very high and is posing perfromacne and
    > > sacalability bottlenecks.

    >
    > A common mistake people make when first using non-blocking I/O is to
    > constantly check their data streams (like sockets or files) for
    > incoming data, without stopping to "take a breath." But if you
    > inserted some kind of sleep or delay into your program to "breathe,"
    > and give your CPU a rest, application performance can be greatly
    > impacted, and when using a networking interface like UDP, you may even
    > lose packets entirely (because your program hadn't cleared the
    > incoming packet buffer when a second one arrived, since your program
    > was sleeping while it happened.)
    >
    > POSIX-compliant APIs offer two facilities which in essence allow your
    > program to sleep without having to worry about losing data or hurting
    > performance. The first is a function called select(), and the second
    > is signal-based I/O. Both are very similar internally, but which you
    > choose to use will depend on how you want to structure your program.
    >
    > Based on what I've read in your email, I think it would be easiest to
    > migrate to a select() paradigm, rather than one of signal-based I/O.
    > Does "VxWorks" offer a method similar to POSIX "select()"? This
    > function allows your program to wait until there is data available on
    > various data streams (like sockets and files.) To select() you specify
    > three arguments which provides the following information to select():
    >
    > - Which data streams your program is waiting for (in POSIX these are
    > represented by "file descriptors," which are merely integers provided
    > by the kernel APIs which refer to data streams like open files and
    > sockets.)
    >
    > - Which types of operations you are waiting for (although for your
    > program, the only operation you are interested in is receiving data.)
    >
    > - The maximum time you wish to wait. If this is zero, then your
    > program will wait indefinitely for whatever sort of activity you
    > specified in the previous two arguments. However you can specify a non-
    > zero value so that your program will "wake up" from the sleep imposed
    > by select() after a certain time has passed, even if no activity
    > specified in your first two arguments has occurred (in your case, the
    > only activity that can occur is new data arriving on UDP sockets.)
    > This "timeout" argument is useful if you wish for your program to
    > perform other tasks on a certain interval even in the absence of data
    > stream activity. It is also useful if you wish to "give up" on waiting
    > for more data, perhaps you have been disconnected from the network, or
    > must check for some other error condition.
    >
    > > As means of improving performacnce I am considering a design where
    > > I can receive I/O notification for each socket from Kernel.

    >
    > As I mentioned earlier, it sounds like it will probably be easier to
    > migrate to a select()-driven design than a signal-driven I/O design.
    >
    > Also as mentioned earlier, the underlying functionality of using
    > select() is very similar to using signal-based I/O. The difference is
    > that instead of signals being received directly by your application,
    > the kernel scheduler merely queues your program to return from
    > sleeping once I/O is available. (In reality, as your process is in
    > SLEEP state while performing select(), this is practically identical
    > to being sent a SIGCONT signal, or "wake-up" signal.)
    >
    > > From my investigation I found that there is
    > > POSIX Async I/O which meet my requirements. Unfortunately, async POSIX
    > > IO is supported for files and not scokets in VxWorks IO.

    >
    > Are you sure about this? To me it seems much more plausible that
    > "VxWorks IO" support asynchronous I/O on sockets, and does not support
    > asynchronous I/O on files. The reason for this is that Windows APIs
    > for asynchronous data stream access only work for sockets, not for
    > files. (This information may be outdated. But it was this way around
    > 2002.)
    >
    > > I am
    > > exploring using Signal facility of VxWorks to achieve asynchrounous
    > > IO notification. I found that there is signal queuing posisble using
    > > sigqueue. I am wondering if I can use this facility to asynchronous IO
    > > notification. Is this possible ? Can this provide good performance ?
    > > VxWorks manul recommends signal usage only for notification or for
    > > error/exception handling. In this view would signal handling be useful
    > > for asynchroous scoket based I/O.

    >
    > It seems very likely to me that if you queued your signals, you would
    > risk missing out on UDP packets as I mentioned earlier. If you receive
    > more than one packet on the same UDP socket before your program has a
    > chance to empty the appropriate buffer, many kernels will simply throw
    > your packet away.
    >
    > > Also assuming that singal based I/O for scokets can be used I
    > > have 2 queries as below :
    > > Is there a facility to get I/O data copied in appliaction passed
    > > buffere while installing signal handler. OR
    > > I use signal I/O as notification for arrival of data on a particular
    > > scoket and then I call recvfrom from my application to get data into
    > > my application buffer.

    >
    > I don't know if "VxWorks" provides this sort of functionality, but
    > neither POSIX nor Windows APIs will do this for you. You must write
    > your own function to copy the packet into program memory so that the
    > kernel has an empty space to put the next packet that it receives on
    > that socket.
    >
    > Hope I was helpful!


    Check VxWorks API once again. It supports select() on all socket/file
    descriptors. If you are still confused on using recvfrom/sendto
    interfaces, try virtual connect on udp socket, after that, you can use
    read/write and select() system call. The last argument to select would
    be the idle time. You need to practically analyze what value should
    work for you better.
    Ranga


  5. Re: Signal based I/O for multiple sockets

    On Jun 13, 2:40 am, "ranga.rav...@gmail.com"
    wrote:
    > On Jun 11, 11:07 pm, Donny Viszneki wrote:
    >
    >
    >
    >
    >
    > > I'm actually 100% unfamiliar with vxWorks, but I'm very familiar with
    > > the underlying APIs that vxWorks must interface with in order to
    > > provide UDP networking on various Unix/Linux and Windows systems.

    >
    > > On Jun 8, 12:26 pm, mustak wrote:

    >
    > > > I observed that by using
    > > > Noblocking I/O multiplexing CPU utilisation for the task which is
    > > > handling UDP packets is very high and is posing perfromacne and
    > > > sacalability bottlenecks.

    >
    > > A common mistake people make when first using non-blocking I/O is to
    > > constantly check their data streams (like sockets or files) for
    > > incoming data, without stopping to "take a breath." But if you
    > > inserted some kind of sleep or delay into your program to "breathe,"
    > > and give your CPU a rest, application performance can be greatly
    > > impacted, and when using a networking interface like UDP, you may even
    > > lose packets entirely (because your program hadn't cleared the
    > > incoming packet buffer when a second one arrived, since your program
    > > was sleeping while it happened.)

    >
    > > POSIX-compliant APIs offer two facilities which in essence allow your
    > > program to sleep without having to worry about losing data or hurting
    > > performance. The first is a function called select(), and the second
    > > is signal-based I/O. Both are very similar internally, but which you
    > > choose to use will depend on how you want to structure your program.

    >
    > > Based on what I've read in your email, I think it would be easiest to
    > > migrate to a select() paradigm, rather than one of signal-based I/O.
    > > Does "VxWorks" offer a method similar to POSIX "select()"? This
    > > function allows your program to wait until there is data available on
    > > various data streams (like sockets and files.) To select() you specify
    > > three arguments which provides the following information to select():

    >
    > > - Which data streams your program is waiting for (in POSIX these are
    > > represented by "file descriptors," which are merely integers provided
    > > by the kernel APIs which refer to data streams like open files and
    > > sockets.)

    >
    > > - Which types of operations you are waiting for (although for your
    > > program, the only operation you are interested in is receiving data.)

    >
    > > - The maximum time you wish to wait. If this is zero, then your
    > > program will wait indefinitely for whatever sort of activity you
    > > specified in the previous two arguments. However you can specify a non-
    > > zero value so that your program will "wake up" from the sleep imposed
    > > by select() after a certain time has passed, even if no activity
    > > specified in your first two arguments has occurred (in your case, the
    > > only activity that can occur is new data arriving on UDP sockets.)
    > > This "timeout" argument is useful if you wish for your program to
    > > perform other tasks on a certain interval even in the absence of data
    > > stream activity. It is also useful if you wish to "give up" on waiting
    > > for more data, perhaps you have been disconnected from the network, or
    > > must check for some other error condition.

    >
    > > > As means of improving performacnce I am considering a design where
    > > > I can receive I/O notification for each socket from Kernel.

    >
    > > As I mentioned earlier, it sounds like it will probably be easier to
    > > migrate to a select()-driven design than a signal-driven I/O design.

    >
    > > Also as mentioned earlier, the underlying functionality of using
    > > select() is very similar to using signal-based I/O. The difference is
    > > that instead of signals being received directly by your application,
    > > the kernel scheduler merely queues your program to return from
    > > sleeping once I/O is available. (In reality, as your process is in
    > > SLEEP state while performing select(), this is practically identical
    > > to being sent a SIGCONT signal, or "wake-up" signal.)

    >
    > > > From my investigation I found that there is
    > > > POSIX Async I/O which meet my requirements. Unfortunately, async POSIX
    > > > IO is supported for files and not scokets in VxWorks IO.

    >
    > > Are you sure about this? To me it seems much more plausible that
    > > "VxWorks IO" support asynchronous I/O on sockets, and does not support
    > > asynchronous I/O on files. The reason for this is that Windows APIs
    > > for asynchronous data stream access only work for sockets, not for
    > > files. (This information may be outdated. But it was this way around
    > > 2002.)

    >
    > > > I am
    > > > exploring using Signal facility of VxWorks to achieve asynchrounous
    > > > IO notification. I found that there is signal queuing posisble using
    > > > sigqueue. I am wondering if I can use this facility to asynchronous IO
    > > > notification. Is this possible ? Can this provide good performance ?
    > > > VxWorks manul recommends signal usage only for notification or for
    > > > error/exception handling. In this view would signal handling be useful
    > > > for asynchroous scoket based I/O.

    >
    > > It seems very likely to me that if you queued your signals, you would
    > > risk missing out on UDP packets as I mentioned earlier. If you receive
    > > more than one packet on the same UDP socket before your program has a
    > > chance to empty the appropriate buffer, many kernels will simply throw
    > > your packet away.

    >
    > > > Also assuming that singal based I/O for scokets can be used I
    > > > have 2 queries as below :
    > > > Is there a facility to get I/O data copied in appliaction passed
    > > > buffere while installing signal handler. OR
    > > > I use signal I/O as notification for arrival of data on a particular
    > > > scoket and then I call recvfrom from my application to get data into
    > > > my application buffer.

    >
    > > I don't know if "VxWorks" provides this sort of functionality, but
    > > neither POSIX nor Windows APIs will do this for you. You must write
    > > your own function to copy the packet into program memory so that the
    > > kernel has an empty space to put the next packet that it receives on
    > > that socket.

    >
    > > Hope I was helpful!

    >
    > Check VxWorks API once again. It supports select() on all socket/file
    > descriptors. If you are still confused on using recvfrom/sendto
    > interfaces, try virtual connect on udp socket, after that, you can use
    > read/write and select() system call. The last argument to select would
    > be the idle time. You need to practically analyze what value should
    > work for you better.
    > Ranga- Hide quoted text -
    >
    > - Show quoted text -


    Seems like there is some confusion. I already have a working version
    using non-blocking Asynchronous I/O and it works fine for 135 sessions
    receiving UDP packets every 20ms for each UDP session. But I see
    performance impact when I try to increase the number of UDP sessions.
    What I am really looking for is the possibility to use Signal based I/
    O such that I register a signal handler along with allocated chunk of
    memory. Now, whenever there is a packet available for a particular
    FD(udp scoket), I get signal which contains data for that particular
    FD and all I have to do is to deliver that data for an application
    object registered for that FD. This way I will seperate notification
    for packet received and Dispatch function. Also, my understading is
    that by doing so I will have improvised performnce and true form of
    Asynchronous I/O. Hope I am making myself clear.

    Mustafa


  6. Re: Signal based I/O for multiple sockets

    On Jun 13, 4:20 pm, mustak wrote:
    > On Jun 13, 2:40 am, "ranga.rav...@gmail.com"
    > wrote:
    >
    >
    >
    >
    >
    > > On Jun 11, 11:07 pm, Donny Viszneki wrote:

    >
    > > > I'm actually 100% unfamiliar with vxWorks, but I'm very familiar with
    > > > the underlying APIs that vxWorks must interface with in order to
    > > > provide UDP networking on various Unix/Linux and Windows systems.

    >
    > > > On Jun 8, 12:26 pm, mustak wrote:

    >
    > > > > I observed that by using
    > > > > Noblocking I/O multiplexing CPU utilisation for the task which is
    > > > > handling UDP packets is very high and is posing perfromacne and
    > > > > sacalability bottlenecks.

    >
    > > > A common mistake people make when first using non-blocking I/O is to
    > > > constantly check their data streams (like sockets or files) for
    > > > incoming data, without stopping to "take a breath." But if you
    > > > inserted some kind of sleep or delay into your program to "breathe,"
    > > > and give your CPU a rest, application performance can be greatly
    > > > impacted, and when using a networking interface like UDP, you may even
    > > > lose packets entirely (because your program hadn't cleared the
    > > > incoming packet buffer when a second one arrived, since your program
    > > > was sleeping while it happened.)

    >
    > > > POSIX-compliant APIs offer two facilities which in essence allow your
    > > > program to sleep without having to worry about losing data or hurting
    > > > performance. The first is a function called select(), and the second
    > > > is signal-based I/O. Both are very similar internally, but which you
    > > > choose to use will depend on how you want to structure your program.

    >

    I am currently using Select system call. Do you mean there is
    a POSIX version of Select available which performs better. If yes, how
    can I control use of BSD style select vs POSIX style select. Also I am
    not sure if VxWorks6.1 supports POSIX style select.

    Also, I noticed that there is POSIX AIO support available. I am not
    sure if this is available for sockets. Is there a way to find out.

    Thanks for your suggestion regardign use of signals for Async IO. I am
    curious to know if someone has experience with it in terms of
    performance for performing based I/O.
    > > > Based on what I've read in your email, I think it would be easiest to
    > > > migrate to a select() paradigm, rather than one of signal-based I/O.
    > > > Does "VxWorks" offer a method similar to POSIX "select()"? This
    > > > function allows your program to wait until there is data available on
    > > > various data streams (like sockets and files.) To select() you specify
    > > > three arguments which provides the following information to select():

    >
    > > > - Which data streams your program is waiting for (in POSIX these are
    > > > represented by "file descriptors," which are merely integers provided
    > > > by the kernel APIs which refer to data streams like open files and
    > > > sockets.)

    >
    > > > - Which types of operations you are waiting for (although for your
    > > > program, the only operation you are interested in is receiving data.)

    >
    > > > - The maximum time you wish to wait. If this is zero, then your
    > > > program will wait indefinitely for whatever sort of activity you
    > > > specified in the previous two arguments. However you can specify a non-
    > > > zero value so that your program will "wake up" from the sleep imposed
    > > > by select() after a certain time has passed, even if no activity
    > > > specified in your first two arguments has occurred (in your case, the
    > > > only activity that can occur is new data arriving on UDP sockets.)
    > > > This "timeout" argument is useful if you wish for your program to
    > > > perform other tasks on a certain interval even in the absence of data
    > > > stream activity. It is also useful if you wish to "give up" on waiting
    > > > for more data, perhaps you have been disconnected from the network, or
    > > > must check for some other error condition.

    >
    > > > > As means of improving performacnce I am considering a design where
    > > > > I can receive I/O notification for each socket from Kernel.

    >
    > > > As I mentioned earlier, it sounds like it will probably be easier to
    > > > migrate to a select()-driven design than a signal-driven I/O design.

    >
    > > > Also as mentioned earlier, the underlying functionality of using
    > > > select() is very similar to using signal-based I/O. The difference is
    > > > that instead of signals being received directly by your application,
    > > > the kernel scheduler merely queues your program to return from
    > > > sleeping once I/O is available. (In reality, as your process is in
    > > > SLEEP state while performing select(), this is practically identical
    > > > to being sent a SIGCONT signal, or "wake-up" signal.)

    >
    > > > > From my investigation I found that there is
    > > > > POSIX Async I/O which meet my requirements. Unfortunately, async POSIX
    > > > > IO is supported for files and not scokets in VxWorks IO.

    >
    > > > Are you sure about this? To me it seems much more plausible that
    > > > "VxWorks IO" support asynchronous I/O on sockets, and does not support
    > > > asynchronous I/O on files. The reason for this is that Windows APIs
    > > > for asynchronous data stream access only work for sockets, not for
    > > > files. (This information may be outdated. But it was this way around
    > > > 2002.)

    >
    > > > > I am
    > > > > exploring using Signal facility of VxWorks to achieve asynchrounous
    > > > > IO notification. I found that there is signal queuing posisble using
    > > > > sigqueue. I am wondering if I can use this facility to asynchronous IO
    > > > > notification. Is this possible ? Can this provide good performance ?
    > > > > VxWorks manul recommends signal usage only for notification or for
    > > > > error/exception handling. In this view would signal handling be useful
    > > > > for asynchroous scoket based I/O.

    >
    > > > It seems very likely to me that if you queued your signals, you would
    > > > risk missing out on UDP packets as I mentioned earlier. If you receive
    > > > more than one packet on the same UDP socket before your program has a
    > > > chance to empty the appropriate buffer, many kernels will simply throw
    > > > your packet away.

    >
    > > > > Also assuming that singal based I/O for scokets can be used I
    > > > > have 2 queries as below :
    > > > > Is there a facility to get I/O data copied in appliaction passed
    > > > > buffere while installing signal handler. OR
    > > > > I use signal I/O as notification for arrival of data on a particular
    > > > > scoket and then I call recvfrom from my application to get data into
    > > > > my application buffer.

    >
    > > > I don't know if "VxWorks" provides this sort of functionality, but
    > > > neither POSIX nor Windows APIs will do this for you. You must write
    > > > your own function to copy the packet into program memory so that the
    > > > kernel has an empty space to put the next packet that it receives on
    > > > that socket.

    >
    > > > Hope I was helpful!

    >
    > > Check VxWorks API once again. It supports select() on all socket/file
    > > descriptors. If you are still confused on using recvfrom/sendto
    > > interfaces, try virtual connect on udp socket, after that, you can use
    > > read/write and select() system call. The last argument to select would
    > > be the idle time. You need to practically analyze what value should
    > > work for you better.
    > > Ranga- Hide quoted text -

    >
    > > - Show quoted text -

    >
    > Seems like there is some confusion. I already have a working version
    > using non-blocking Asynchronous I/O and it works fine for 135 sessions
    > receiving UDP packets every 20ms for each UDP session. But I see
    > performance impact when I try to increase the number of UDP sessions.
    > What I am really looking for is the possibility to use Signal based I/
    > O such that I register a signal handler along with allocated chunk of
    > memory. Now, whenever there is a packet available for a particular
    > FD(udp scoket), I get signal which contains data for that particular
    > FD and all I have to do is to deliver that data for an application
    > object registered for that FD. This way I will seperate notification
    > for packet received and Dispatch function. Also, my understading is
    > that by doing so I will have improvised performnce and true form of
    > Asynchronous I/O. Hope I am making myself clear.
    >
    > Mustafa- Hide quoted text -
    >
    > - Show quoted text -




+ Reply to Thread