Skip to main content

Writing a TCP/UDP stack supporting the SIP protocol using the Grizzly Framework

Posted by jfarcand on February 12, 2008 at 9:53 AM PST

This blog has moved here

Related Topics >>

Comments

Writing a TCP/UDP stack

I always interested in such innovtive work,your article have depth knowledge which is very useful for "http://www.certsquare.com/braindumps/VCP-410.php" and helpful for "http://www.certsquare.com/braindumps/640-802.php"

Where is the stack for filtering the SIP messages.Do you have the full source code in samples or somewhere we can download and study.

The way Grizzly is designed differ from the IoHandlerAdapter/IoSession. In Grizzly, you will find the same set of functionalities by using the Context , which is passed to a ProtocolFilter. This is probably a bad association, but it seems the ProtocolFilter is something similar to the IoHandler, and the IoSession similar to the Context. But long time I looked at MINA so my understanding is probably wrong. Anyway you have the same info with Context/ProtocolFilter, and we could probably add to the framework something similar to Mina where Grizzly pushes some events to a specific method from a ProtocolFilter. We just need to add an interface on top of the ProtocolFilter...will think of it :-) Thanks!

Bonjour JF. I'm currently looking for an alternative for our current TCP/UPP connector in our gateways at my jobs. Most of our network connections handling are done on home made stuff, made few years ago. I saw few options, create again our own librairies (don't want to), Mina and Grizzly. I really want to try Grizzly, but I don't know where to start. You seem to have the only good forum for grizzly :) Your example seem to do the job for a starting point, but can you help me by giving me few tips are ? How do I create a Basic server (like your echoserver) that will accept multiple connections make from non NIO clients (like telnet) ? I will like to have the blocking and non blocking option (for our legacy gateways, they wait until a timeout). merci Sébastien

Great tutorial! Things are starting to get clearer with Grizzly. Thanks. Correct me if I'm wrong. There is a one-to-one relationship between a protocolChainInstanceHandler and a Controller? This means that for a given server, we can listen to many ports using many transport protocols, but the information (the bytes) received will all be handled by the same protocolChain. My interrogation is motivated by the following: I want to listen to port pA and handle the information received using protocolChain cA and listen to port pB using protocolChain cB. Would you recommend creating 2 controllers? If so, can I share a common thread pool (pipeline) between the two? Thanks... Guess I should have asked this on the forum... thanks anyway.

Hi Sebastien, The best way to start is to subscribe to the users@grizzly.dev.java.net where the community can help you very fast to start. Do you mind sending your request there? If you can't, ping me again and I will add the information here, but I would really like to have the community (including me :-)) to answer :-) This is easy to implement what you want with Grizzly :-) Thanks! -- Jeanfrancois

Salut,

[ProtocolChain] -> It depends on which strategy you want to implement. You can associate one ProtocolChain per Request (the statefull approach), or one ProtocolChain shared amongs all requests (stateless approach). The ProtocolChain can be shared amongs all SelectorHandler if you do:

Controller.setProtocolChainInstanceHandler()

or you can set it per SelectorHandler:

SelectorHandler.setProtocolChainInstanceHandler()

So to answer your last question, your don't need to have 2 Controller, just need to create two instance of a ProtocolChainInstanceHandler, and set them on the SelectorHandler handling cA and cB :-)

Thanks!

Thanks, it exactly answers my question. I'm looking forward to your next instalment to this tutorial. I am most interested in knowing how to pass the received bytes to the business logic tier. As a current MINA user, I am most interested in knowing if Grizzly has a construct similar to Mina's IoHandlerAdapter (http://mina.apache.org/report/trunk/xref/org/apache/mina/common/IoHandlerAdapter.html). This IoHandlerAdapter construct is a good high level demarcation point between business logic tier and I/O related logic. Thanks.

Some more precision for my request: I made: import com.sun.grizzly.ProtocolParser; but it is not accepted. The external Jar that I add is grizzly-framework-1.7.3.2.jar THANK YOU

Bonjour JF. I am trying to create my one protocolparserfilter but I can't find the package for ProtocolParser. Could you help me please! thanks

Hello, Thanks for those valourous clarifications on the use of Grizzly to implement a transport application. I just discover Grizzly today because I was looking for a NIO application because I aim to implement a probe with UDP transport, and for that purpose I need to know how to access to the bytes read by the ReadFilter to interpret for example the response of a client.

Am I missing something

Am I missing something necessary to reliably access a Coyote HttpServletRequest implementation from a separate thread? The errors also seem to multiply the more times I use the upload form. Am I not closing out the CometHandler and the original request/response correctly? My name is Kevin Rosen and I'm a fan of Pariuri Sportive and Clasamente Fotbal. My favorite CMS is Wordpress. Drupal is the second. I know basic HTML, CSS and PHP.

<p>Well worth.Thanks , very good article it worth to read. ...

Well worth.Thanks , very good article it worth to read. Not much I can handle the TCP protocol, but my favorite is wordpress platform. Hello, Thanks for those valourous clarifications on the use of Grizzly to implement a transport application. I just discover Grizzly today because I was looking for a NIO application because I aim to implement also.I am very passioned also of Calculatoare Second Hand