Hi Kyle,

LLRP is a layer above TCP (at least the currently defined binary is).
When a reader connects to a client or vice versa, it's always up to the
reader to send the first message (ConnectionStatusEvent in a
READER_EVENT_NOTIFICATION.  Once a client receives this, whether on the
initating or accepting end of the TCP connection, it can issue commands
to the reader.

You are right, the spec does not say how the reader is commanded to
initiate connections or for that matter, how a client is commanded to
initiate connections.  I think the spec developers wanted to give
flexibility to product definition.

Readers typically have command shells, web interfaces, SNMP, and/or DHCP
to provision them. I'd expect that vendors would use one or more of
these methods to command a reader to make client connections. EPCglobal
also have a spot for a protocol which may serve this purpose, although
it is not expected to be ratified in 2007.

http://www.epcglobalinc.org/standards/dci 




-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Kyle
Sent: Tuesday, September 18, 2007 8:30 AM
To: LLRP Toolkit Development List
Subject: [ltk-d] LLRP Connection Question [heur]

I was looking at the LLRP Connection Section in the Spec (chapter 18), 
and I have a couple of questions about it.  To me, it seems like there 
is kind of an "LLRP layer" that sits above the TCP layer that you have 
to be connected to before you can issue any LLRP Commands.  The spec 
says that the reader has to be able to both initiate and accept this 
LLRP connection, but it does not specify how it is supposed to do that. 
(For example, it is undefined how to command the reader to initiate an 
LLRP connection with a client). What is the intention behind not 
specifying this, and how is it imagined that vendors will deal with this

issue?  Should vendors write their own connection commands?  Or is there

some kind of standard way to handle this problem?

Thanks,
Kyle

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
llrp-toolkit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
llrp-toolkit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel

Reply via email to