Thank you Jean-Francois ... <
http://weblogs.java.net/blog/jfarcand/>
I don't close the connection. AS far as I can see the connection is opened
once(unless modem power-off or telecomms reset ip's)
By the way, my server is purely passive.. (don't actively open connection to
modem)
- if it receives a polling message, echo back, if it's a reply match with
request. The polling message has an id which I then use to check whether
there are any pending requests - if so, send request.
- and resume listening,
- if it receives a polling message, echo back, if it's a reply match with
request.. rinse lather repeat.
P.s. I'll try and see if ip's can be used in a "best effort" kind of way..
Kind Regards
Pete
On Tue, Oct 14, 2008 at 6:44 PM, Jeanfrancois Arcand <
Jeanfrancois.Arcand_at_sun.com> wrote:
> Salut,
>
> P J wrote:
>
>> Hello Jeanfrancois,
>>
>> Thanks for the reply!
>>
>> Can you elaborate on the above scenario? I would like to understand it
>> more...but should the protocol used between the server and the modem include
>> a special "header" that describe you is sending back the response? Of you
>> might use the IP address to detect from which modem the response if from.
>>
>> Quick question: are you defining the protocol between your server and
>> modem, or you already have a text/bytes protocol that you can't change?
>>
>> The protocol is fixed - I can't define/change it :-( (I suppose
>> technically a rewrite of firmware could change the protocol,but thats not an
>> option now)
>>
>
> I agree :-) Pouaaa
>
> Elaborate...ok, suppose I send a request to the modem $ST+VERSION the
>> reply I get would look something like $ST+VERSION=1.13 ..the problem I am
>> experiencing(I can just hear grizzly experts rolling around laughing) is
>> that, I need to determine from which modem this came. Remember, many similar
>> requests might be sent at once, and the replies would be coming in at
>> different times, so matching request with response is critical.
>> Using the IP would be a nice solution, so for testing I tried it... the
>> only concern I have is that IPs are volatile - they seem to change every so
>> often... what if I sent a request and the IP changes? Worst: What if I get a
>> "false" match? That would be failure!
>>
>
> Thanks for the info. Is your protocol by-directional, e.g. you open a
> connection to the modem, then close the connection OR wait for a response?
> In the latter case, the IP should not change. In the former case, then yes
> inbetween the server->modem and modem->server the IP might have changed. In
> that case I don't see how you can found who is calling back without being
> able to add something to the request/response (like a headers/token).
>
> Does it help?
>
> A+
>
> -- Jeanfrancois
>
>
>
>
>
>> Welcoming you suggestions
>> Kind Regards Pete
>>
>>
>>
>>
>>
>> On Tue, Oct 14, 2008 at 4:38 PM, Jeanfrancois Arcand <
>> Jeanfrancois.Arcand_at_sun.com <mailto:Jeanfrancois.Arcand_at_sun.com>> wrote:
>>
>> Salut,
>>
>> sorry for the delay, was on vacation :-)
>>
>> P J wrote:
>>
>> RE: My question pertains to the use of the Grizzly Framework
>> being used to communicate with hardware devices.
>>
>> Hello all,
>>
>> If this is not the correct way to ask questions, please direct
>> me to the appropriate forum.
>>
>>
>> Quick background:
>> * The hardware devices are gprs modems, with embedded
>> software(which
>> I do not have code access to - so it's a constant) These
>> modems
>> are programmed to a very simple protocol, and can perform a
>> few
>> operations.
>> * I am tasked to write a central server. The modems will poll my
>> software, to which I will echo back... on occasion I will send
>> through an operation request(self test, or parameter
>> updates...)
>> and of course receive "OKs" back.
>> * My server application has to in JAVA.
>> * At any point in time I might have to handle hundreds or even
>> thousands of connections.
>> * Using a blog example(Using Grizzly to read TCP Packets:
>> <
>> http://gallemore.blogspot.com/2007/07/using-grizzly-to-read-tcp-packets.html
>> >
>> http://gallemore.blogspot.com/2007/07/using-grizzly-to-read-tcp-packets.html
>> )
>>
>> <
>> http://gallemore.blogspot.com/2007/07/using-grizzly-to-read-tcp-packets.html
>> >I
>> got an echo server running successfully - qualify, I'm getting
>> polling messages.
>> <
>> http://gallemore.blogspot.com/2007/07/using-grizzly-to-read-tcp-packets.html
>> >
>> * I'm a multiple threads programmer... learning the NIO
>> ropes, this
>>
>> all is a bit different :-)
>>
>>
>> My questions are as follow:
>>
>> 1. Would Grizzly be an appropriate technology for this type of
>> application?
>>
>>
>> Yes.
>>
>> 2. It's so difficult to get relevant documentation. Are there
>> any
>>
>> pdf's, e-books, printed books that would be beneficial to
>> read?
>>
>>
>> Take a look at the following entries:
>>
>>
>> http://weblogs.java.net/blog/jfarcand/archive/2008/02/writing_a_tcpud_1.html
>>
>> https://grizzly.dev.java.net/tutorials/tutorial-framework-filter-sample/index.html
>>
>>
>> 3. I've tried expanding the example to use callbacks. (Reason: I
>>
>> might send a request to a modem 1, and whilst waiting for the
>> response, need to tend to a polling message from modem 2,
>> but once
>> the reply-results arrive, I need to know that the message came
>> from modem 1, because the message might not carry an
>> identifying
>> id - for example, an OK message has no modem ID - this of
>> course
>> is no problem with a 1-to-1 conversation,but with thousands
>> it's a
>> nightmare!) :-(
>>
>>
>> Can you elaborate on the above scenario? I would like to understand
>> it more...but should the protocol used between the server and the
>> modem include a special "header" that describe you is sending back
>> the response? Of you might use the IP address to detect from which
>> modem the response if from.
>>
>> Quick question: are you defining the protocol between your server
>> and modem, or you already have a text/bytes protocol that you can't
>> change?
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>>
>>
>> Kind Regards,
>> Pete
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> <mailto:users-unsubscribe_at_grizzly.dev.java.net>
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>> <mailto:users-help_at_grizzly.dev.java.net>
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>