Announcement Announcement Module
No announcement yet.
Receiving multicast non http packets from a broadcast server Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Receiving multicast non http packets from a broadcast server


    I have a server multicasting information. For the moment, this information are multicasted on a LAN without any specific format (I mean XML and so on) or high level procotol (like http).
    On the other side, I have several clients (that are web application: tomcat is the web server).

    I would like to do a simple design. What cannot be change is multicasting.

    For the moment:

    On the server side:
    MulticastSocket are used, with serialialization of one specific Object: simple and efficient. Later, if I want to serialize more object, I can improve that using JAXB.

    On the client side:
    I've tried to use a bean with MulticastSocket. I wrote the definition of the bean inside the servlet.xml definition. The thread is working but Tomcat is not anymore responding to any request.

    And the link "Safe-thread with spring is not anymore rachable":

    So, my conclusion is either
    1- to extend GenericServlet and read input. But I'm not very strong with that, and I don't know what have to be done (web.xml and so on) to run the servlet on a multicast port. I see there is "" to allow multicast socket in the tomcat documentation but that's all.
    2- to create a local EJB inside an application server (Jonas for example). I think the EJB would inherit from GenericServlet too. I think there is no added functionnalities since the EJB receiving multicast packets must be on the same system as the web server. So using jndi for nothing is not my cup of tea.

    My questions are:
    Do you think 1) is the best design ?
    If so, how to:
    - use multicast with GenericServlet
    - how to configure the tomcat and web.xml fiels correctly ?


  • #2
    I think this is one of the areas where J2EE is not going to help much. The most brute force method I can think of would be to write your own thread/TCP listener. I've never used it, but the QuickServer project might help with this:


    • #3
      Thank you very much for your answer. I didn't hear about this project. It's great.