|
View:
New views
11 Messages
—
Rating Filter:
Alert me
|
|
|
TCP Responses to ClientHi All,
I am trying to get a TCP server running to parse my own protocol, which I have since found many examples on. But one thing I am currently stuck on is how to write a response to the client that connected. I am using JMeter to connect a TCP session and send some data, and I seem to never get a response to to any message that I send. This is largely due to the fact that I dont know where exactly to write anything to the client. Do I do it in one of the protocolfilters? Or do I have to write something to a SelectableChannel? Any help is greatly appreciated. Cheers, Mark |
|
|
Re: TCP Responses to ClientHello Mark,
if you want maybe you could post your Jmeter code to the users@... ? I could take a look there and I think some other users might then have sugesstions for you.. The best solution depends on your protocol: for many protocols it often works to just stay on the protocoChain transaction and call com.sun.grizzly.util.OutputWriter.flushChannel when you have read in the client message. Maybe context.getAsyncQueueWritable().writeToAsyncQueue(byteBuffer) would also make sense. it really depends on your server code (-: Many Greetings John -------- Original-Nachricht -------- > Datum: Wed, 23 Jul 2008 15:07:41 +1000 > Von: "Mark Macumber" <mark.macumber@...> > An: dev@... > Betreff: TCP Responses to Client > Hi All, > > I am trying to get a TCP server running to parse my own protocol, which I > have since found many examples on. But one thing I am currently stuck on > is > how to write a response to the client that connected. > > I am using JMeter to connect a TCP session and send some data, and I seem > to > never get a response to to any message that I send. This is largely due to > the fact that I dont know where exactly to write anything to the client. > Do > I do it in one of the protocolfilters? Or do I have to write something to > a > SelectableChannel? > > Any help is greatly appreciated. > > Cheers, > Mark -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: TCP Responses to ClientHi John,
So it appears that I may have been on the wrong track, I was actually getting a response when I used, OutputWriter.flushChannel The miss-leading thing to me was that JMeter did not appear to be getting a response because the connection was still open, not like with HTTP where the connection is closed... So, when I did this: SelectableChannel selectableChannel = ctx.getSelectionKey().channel(); OutputWriter.flushChannel(selectableChannel, messageResponse.getMessageData()); selectableChannel.close(); I got an immediate "notification" (visual response) from JMeter that showed me that it received the bytes from my filter. If I removed the close() call and waited for approx. 30 seconds, then I also got this response as (i guess) the connection timed out and closed itself... Cheers, Mark On Wed, Jul 23, 2008 at 5:02 PM, John ROM <snake-john@...> wrote: Hello Mark, |
|
|
Re: TCP Responses to ClientSalut,
Mark Macumber wrote: > Hi John, > > So it appears that I may have been on the wrong track, I was actually > getting a response when I used, > > OutputWriter.flushChannel > > The miss-leading thing to me was that JMeter did not /appear/ to be > getting a response because the connection was still open, not like with > HTTP where the connection is closed... > > So, when I did this: > > SelectableChannel selectableChannel = ctx.getSelectionKey().channel(); > OutputWriter.flushChannel(selectableChannel, > messageResponse.getMessageData()); > *selectableChannel.close();* > > I got an immediate "notification" (visual response) from JMeter that > showed me that it received the bytes from my filter. > > If I removed the close() call and waited for approx. 30 seconds, then I > also got this response as (i guess) the connection timed out and closed > itself... Yes, this is the default time out when a connection is idle. It seems to me that JMeter is waiting for the connection to be closed....when you tested using HTTP, were you using HTTP 1.0? With 1.0, the connection are automatically closed, which I suspect was the behavior you were seeing. Thanks -- Jeanfrancois > > Cheers, > Mark > > On Wed, Jul 23, 2008 at 5:02 PM, John ROM <snake-john@... > <mailto:snake-john@...>> wrote: > > Hello Mark, > if you want maybe you could post your Jmeter code to the > users@... <mailto:users@...> ? > > I could take a look there and I think some other users might then > have sugesstions for you.. > > The best solution depends on your protocol: > > for many protocols it often works to just stay on the protocoChain > transaction > and call > com.sun.grizzly.util.OutputWriter.flushChannel when you have read in > the client message. > Maybe context.getAsyncQueueWritable().writeToAsyncQueue(byteBuffer) > would also make > sense. it really depends on your server code (-: > > Many Greetings John > > > -------- Original-Nachricht -------- > > Datum: Wed, 23 Jul 2008 15:07:41 +1000 > > Von: "Mark Macumber" <mark.macumber@... > <mailto:mark.macumber@...>> > > An: dev@... <mailto:dev@...> > > Betreff: TCP Responses to Client > > > Hi All, > > > > I am trying to get a TCP server running to parse my own protocol, > which I > > have since found many examples on. But one thing I am currently > stuck on > > is > > how to write a response to the client that connected. > > > > I am using JMeter to connect a TCP session and send some data, > and I seem > > to > > never get a response to to any message that I send. This is > largely due to > > the fact that I dont know where exactly to write anything to the > client. > > Do > > I do it in one of the protocolfilters? Or do I have to write > something to > > a > > SelectableChannel? > > > > Any help is greatly appreciated. > > > > Cheers, > > Mark > > -- > GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! > Jetzt dabei sein: > http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > <mailto:dev-unsubscribe@...> > For additional commands, e-mail: dev-help@... > <mailto:dev-help@...> > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: TCP Responses to ClientHello Jeanfrancois,
Yes that is correct I believe we were using HTTP 1.0, so that explains everything. :) Cheers, Mark On Thu, Jul 24, 2008 at 10:49 AM, Jeanfrancois Arcand <Jeanfrancois.Arcand@...> wrote: Salut, |
|
|
Re: TCP Responses to ClientSalut,
Mark Macumber wrote: > Hello Jeanfrancois, > > Yes that is correct I believe we were using HTTP 1.0, so that explains > everything. :) :-). Now an alternative solution is to set, inside your ProtocolFilter: Context.setKeyRegistrationState(Context.KeyRegistrationState.CANCEL); This will close the connection for you. A+ -- Jeanfrancois > > Cheers, > Mark > > > On Thu, Jul 24, 2008 at 10:49 AM, Jeanfrancois Arcand > <Jeanfrancois.Arcand@... <mailto:Jeanfrancois.Arcand@...>> wrote: > > Salut, > > > Mark Macumber wrote: > > Hi John, > > So it appears that I may have been on the wrong track, I was > actually getting a response when I used, > > OutputWriter.flushChannel > > The miss-leading thing to me was that JMeter did not /appear/ to > be getting a response because the connection was still open, not > like with HTTP where the connection is closed... > > So, when I did this: > > SelectableChannel selectableChannel = > ctx.getSelectionKey().channel(); > OutputWriter.flushChannel(selectableChannel, > messageResponse.getMessageData()); > *selectableChannel.close();* > > I got an immediate "notification" (visual response) from JMeter > that showed me that it received the bytes from my filter. > > If I removed the close() call and waited for approx. 30 seconds, > then I also got this response as (i guess) the connection timed > out and closed itself... > > > Yes, this is the default time out when a connection is idle. It > seems to me that JMeter is waiting for the connection to be > closed....when you tested using HTTP, were you using HTTP 1.0? With > 1.0, the connection are automatically closed, which I suspect was > the behavior you were seeing. > > Thanks > > -- Jeanfrancois > > > > Cheers, > Mark > > > On Wed, Jul 23, 2008 at 5:02 PM, John ROM <snake-john@... > <mailto:snake-john@...> <mailto:snake-john@... > <mailto:snake-john@...>>> wrote: > > Hello Mark, > if you want maybe you could post your Jmeter code to the > users@... > <mailto:users@...> > <mailto:users@... > <mailto:users@...>> ? > > > I could take a look there and I think some other users might then > have sugesstions for you.. > > The best solution depends on your protocol: > > for many protocols it often works to just stay on the > protocoChain > transaction > and call > com.sun.grizzly.util.OutputWriter.flushChannel when you have > read in > the client message. > Maybe > context.getAsyncQueueWritable().writeToAsyncQueue(byteBuffer) > would also make > sense. it really depends on your server code (-: > > Many Greetings John > > > -------- Original-Nachricht -------- > > Datum: Wed, 23 Jul 2008 15:07:41 +1000 > > Von: "Mark Macumber" <mark.macumber@... > <mailto:mark.macumber@...> > <mailto:mark.macumber@... > <mailto:mark.macumber@...>>> > > An: dev@... > <mailto:dev@...> > <mailto:dev@... <mailto:dev@...>> > > > Betreff: TCP Responses to Client > > > Hi All, > > > > I am trying to get a TCP server running to parse my own > protocol, > which I > > have since found many examples on. But one thing I am > currently > stuck on > > is > > how to write a response to the client that connected. > > > > I am using JMeter to connect a TCP session and send some data, > and I seem > > to > > never get a response to to any message that I send. This is > largely due to > > the fact that I dont know where exactly to write anything > to the > client. > > Do > > I do it in one of the protocolfilters? Or do I have to write > something to > > a > > SelectableChannel? > > > > Any help is greatly appreciated. > > > > Cheers, > > Mark > > -- > GMX startet ShortView.de. Hier findest Du Leute mit Deinen > Interessen! > Jetzt dabei sein: > http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > <mailto:dev-unsubscribe@...> > <mailto:dev-unsubscribe@... > <mailto:dev-unsubscribe@...>> > > For additional commands, e-mail: > dev-help@... <mailto:dev-help@...> > <mailto:dev-help@... > <mailto:dev-help@...>> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > <mailto:dev-unsubscribe@...> > For additional commands, e-mail: dev-help@... > <mailto:dev-help@...> > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: TCP Responses to ClientHi,
Thanks for the tip, is this the same as doing: SelectableChannel selectableChannel = ctx.getSelectionKey().channel(); selectableChannel.close(); ?? Either way, we are really trying to work with keep-alive here, so closing the connection will be great for testing the actual response sent, but thats all, we need to make sure that we are also testing that the connection doesn't close, but get the correct response. Cheers, Mark On Thu, Jul 24, 2008 at 11:02 AM, Jeanfrancois Arcand <Jeanfrancois.Arcand@...> wrote: Salut, |
|
|
Re: TCP Responses to ClientSalut,
Mark Macumber wrote: > Hi, > > Thanks for the tip, is this the same as doing: > > SelectableChannel selectableChannel = ctx.getSelectionKey().channel(); > selectableChannel.close(); > > ?? It is better to let the framework close the channel and recycle its internal object with the solution I'm proposing. It really do exactly what you have described. > > Either way, we are really trying to work with keep-alive here, so > closing the connection will be great for testing the actual response > sent, but thats all, we need to make sure that we are also testing that > the connection doesn't close, but get the correct response. I see. I think the problem is with JMeter. If you try to telnet the port (or use another client), does the client gets the response? You might also want to manipulate the idle time: ((DefaultSelectionKeyHandler)ctx.getSelectorHandler().getSelectionKeyHandler()).setTimeout(<<timeinMiliseconds>>); By default, we close idel to 30 seconds. A+ -- Jeanfrancois > > Cheers, > Mark > > On Thu, Jul 24, 2008 at 11:02 AM, Jeanfrancois Arcand > <Jeanfrancois.Arcand@... <mailto:Jeanfrancois.Arcand@...>> wrote: > > Salut, > > > Mark Macumber wrote: > > Hello Jeanfrancois, > > Yes that is correct I believe we were using HTTP 1.0, so that > explains everything. :) > > > :-). Now an alternative solution is to set, inside your ProtocolFilter: > > Context.setKeyRegistrationState(Context.KeyRegistrationState.CANCEL); > > This will close the connection for you. > > A+ > > -- Jeanfrancois > > > > Cheers, > Mark > > > > On Thu, Jul 24, 2008 at 10:49 AM, Jeanfrancois Arcand > <Jeanfrancois.Arcand@... > <mailto:Jeanfrancois.Arcand@...> > <mailto:Jeanfrancois.Arcand@... > <mailto:Jeanfrancois.Arcand@...>>> wrote: > > Salut, > > > Mark Macumber wrote: > > Hi John, > > So it appears that I may have been on the wrong track, I was > actually getting a response when I used, > > OutputWriter.flushChannel > > The miss-leading thing to me was that JMeter did not > /appear/ to > be getting a response because the connection was still > open, not > like with HTTP where the connection is closed... > > So, when I did this: > > SelectableChannel selectableChannel = > ctx.getSelectionKey().channel(); > OutputWriter.flushChannel(selectableChannel, > messageResponse.getMessageData()); > *selectableChannel.close();* > > I got an immediate "notification" (visual response) from > JMeter > that showed me that it received the bytes from my filter. > > If I removed the close() call and waited for approx. 30 > seconds, > then I also got this response as (i guess) the connection > timed > out and closed itself... > > > Yes, this is the default time out when a connection is idle. It > seems to me that JMeter is waiting for the connection to be > closed....when you tested using HTTP, were you using HTTP > 1.0? With > 1.0, the connection are automatically closed, which I suspect was > the behavior you were seeing. > > Thanks > > -- Jeanfrancois > > > > Cheers, > Mark > > > On Wed, Jul 23, 2008 at 5:02 PM, John ROM > <snake-john@... <mailto:snake-john@...> > <mailto:snake-john@... <mailto:snake-john@...>> > <mailto:snake-john@... <mailto:snake-john@...> > > <mailto:snake-john@... <mailto:snake-john@...>>>> > wrote: > > Hello Mark, > if you want maybe you could post your Jmeter code to the > users@... > <mailto:users@...> > <mailto:users@... > <mailto:users@...>> > <mailto:users@... > <mailto:users@...> > <mailto:users@... > <mailto:users@...>>> ? > > > I could take a look there and I think some other users > might then > have sugesstions for you.. > > The best solution depends on your protocol: > > for many protocols it often works to just stay on the > protocoChain > transaction > and call > com.sun.grizzly.util.OutputWriter.flushChannel when > you have > read in > the client message. > Maybe > > context.getAsyncQueueWritable().writeToAsyncQueue(byteBuffer) > would also make > sense. it really depends on your server code (-: > > Many Greetings John > > > -------- Original-Nachricht -------- > > Datum: Wed, 23 Jul 2008 15:07:41 +1000 > > Von: "Mark Macumber" <mark.macumber@... > <mailto:mark.macumber@...> > <mailto:mark.macumber@... > <mailto:mark.macumber@...>> > <mailto:mark.macumber@... > <mailto:mark.macumber@...> > <mailto:mark.macumber@... > <mailto:mark.macumber@...>>>> > > An: dev@... > <mailto:dev@...> > <mailto:dev@... > <mailto:dev@...>> > <mailto:dev@... > <mailto:dev@...> > <mailto:dev@... <mailto:dev@...>>> > > > > Betreff: TCP Responses to Client > > > Hi All, > > > > I am trying to get a TCP server running to parse my own > protocol, > which I > > have since found many examples on. But one thing I am > currently > stuck on > > is > > how to write a response to the client that connected. > > > > I am using JMeter to connect a TCP session and send > some data, > and I seem > > to > > never get a response to to any message that I send. > This is > largely due to > > the fact that I dont know where exactly to write > anything > to the > client. > > Do > > I do it in one of the protocolfilters? Or do I have > to write > something to > > a > > SelectableChannel? > > > > Any help is greatly appreciated. > > > > Cheers, > > Mark > > -- > GMX startet ShortView.de. Hier findest Du Leute mit Deinen > Interessen! > Jetzt dabei sein: > > http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > dev-unsubscribe@... > <mailto:dev-unsubscribe@...> > <mailto:dev-unsubscribe@... > <mailto:dev-unsubscribe@...>> > <mailto:dev-unsubscribe@... > <mailto:dev-unsubscribe@...> > <mailto:dev-unsubscribe@... > <mailto:dev-unsubscribe@...>>> > > For additional commands, e-mail: > dev-help@... > <mailto:dev-help@...> > <mailto:dev-help@... > <mailto:dev-help@...>> > <mailto:dev-help@... > <mailto:dev-help@...> > <mailto:dev-help@... > <mailto:dev-help@...>>> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > <mailto:dev-unsubscribe@...> > <mailto:dev-unsubscribe@... > <mailto:dev-unsubscribe@...>> > For additional commands, e-mail: > dev-help@... <mailto:dev-help@...> > <mailto:dev-help@... > <mailto:dev-help@...>> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > <mailto:dev-unsubscribe@...> > For additional commands, e-mail: dev-help@... > <mailto:dev-help@...> > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: TCP Responses to ClientHi, I agree that JMeter is the issue here, I have not really had much experience with telnetting, but I will give it a go, or delegate to the tester here to make sure that we can somehow test the responses. Is there any examples out there is TCP client testing? I will go through the unit tests now to check what we can do... That timeout property will come in handy too! We need that to be configurable so that our app closes client abandoned connections... Cheers, Mark On Thu, Jul 24, 2008 at 11:14 AM, Jeanfrancois Arcand <Jeanfrancois.Arcand@...> wrote: Salut, |