> Are multiple TCP/IP connections/sessions also allowed at the Reader?  Why or
> why not?   

SLRRP does not have a "session ID". By definition, a SLRRP channel is a
single session. If the Reader allows multiple SLRRP channels to exist,
then it is the responsibility of the Reader's design to handle it and is
outside the scope of SLRRP. 
To be clear, SLRRP does not require multiple sessions to be opened. 


> Also, if a connection is lost, is state (e.g. previous access specs)
> maintained, or lost or reinitialized?
> 
That is beyond SLRRP too! SLRRP is an interface protocol - its
stateless. Its an end-node issue. The host and the reader are stateful
and should be keeping the state until and unless the node got
reset/rebooted or state-update from the other end-node.

> I *really* like the "lightweight" nature of SLRRP, and all the above
> introduce another level of complexity, and I was just curious as to the
> current thinking on these issues.

I am not inclined to add any complexity. If you think handling multiple
commands in flight is an issue, then lets discuss that. Here are my
thoughts ...

Some Readers internally have a serialized architecture (single
threaded), thereby allowing only a single command to be processed at a
time. This means the commands may need to buffered at the receive
interface of the Reader.

All the commands in SLRRP from the host require an response from the
reader. If the host chose to send multiple commands, then it is the
host's responsibility to keep track of the command fulfillment @ the
reader.

Allowing multiple commands in flight in an network interface protocol
does not (and should not) force multi-threaded design in a reader. On
the same token, a single-threaded reader design should not force the
interface protocol to be serialized (i.e., only one unacked command in
flight).

I hope this helps.

Thanks,
/Krishna

> 
> Suresh
> 
> -----Original Message-----
> From: P. Krishna [mailto:pkrishna@revasystems.com] 
> Sent: Wednesday, May 25, 2005 8:43 AM
> To: Suresh Bhaskaran
> Cc: rfid@ietf.org
> Subject: Re: [Rfid] SLRRP-related questions
> 
> 
> 
> On Tue, 2005-05-24 at 19:45, Suresh Bhaskaran wrote:
> > Krishna, et. al:
> > Here are some questions I collected up relating to SLRRP:
> >  
> > 
> >      1. How do you set server IP address and port (into reader) if
> >         reader initiates connection?! 
> >              a. (telnet is one way; web server is another?!) 
> 
> This falls into the 'discovery and configuration' bucket and is not a
> SLRRP protocol issue. In anycase, I can give you a brief overview of how
> it can be addressed using DHCP. This is one of many ways to do it. 
> 
> A reader upon bootup DHCPs for an IP address. In the DHCP message the
> reader also requests for a configuration file and maybe a tftp server IP
> address from where to fetch the config file. 
> 
> The reader configuration file can contain 
> - IP addresses of the upstream RNC(s) 
> - NTP server
> - operating profile, etc
> 
> The reader then initiates the connection to the RNC.
> 
> >      1. What comes back as message sequence number if you have
> >         multiple packet responses per command? 
> >              a. E.g. Inventory Access Report 
> 
> Its the message sequence number and not packet sequence number - its not
> used for re-sequencing. Since we allow multiple outstanding commands in
> the SLRRP channel, it is useful to correspond the response to the
> command. An implementation in SLRRP layer may choose to make use of it
> or not. Especially, for asynchronous responses, the message sequence
> number has no relevance.
> 
> If there are multiple packet responses per command, they will contain
> the same message sequence number. The underlying transport layer (TCP)
> does the packet sequencing and presents the packets in 'transmitted'
> order to the SLRRP layer at the receiving end. 
> 
> In the case of inventory-access-report, the message sequence number
> corresponds only to the inventory command and not to the access
> command(s). As you might be aware that each access command creates an
> access-spec at the reader. We can multiple access-specs created at the
> reader at any time. 
> 
> An inventory command on the other hand, causes the reader to send
> over-the-air protocol commands to singulate/inventory the population of
> tags. For any tags matching one or more of the the access-spec(s) stored
> in the reader, a corresponding access operation (read user memory, lock,
> etc) on the tag.
> 
> 
> 
> >      1. Reader Status report comes asynchronously.  What is it's
> >         sequence number? 
> >              a. (could set to 0) 
> 
> Yes - it is set to 0 and ignored at the receiving end.
> 
> 
> >      1. What if Reader Status report comes asynchronously?  What
> >         happens? 
> 
> The role of SLRRP ends after it has conveyed the reader status report to
> the RNC. What happens upon receipt of the reader status report, depends
> on the implementation/logic residing in the RNC.
> 
> 
> >      1. What happens if Stop Inventory, and there is partial data to
> >         be returned?! 
> A reader upon receiving a "Stop Inventory" command stops sending the
> over-the-air commands - i.e., stops the singulation/inventory.
> 
> Its kind of decoupled from when data is sent back to the RNC.
> 
> The logic in the reader that drives when to send the data back to RNC is
> determined by the configuration setting conveyed by the "Inventory and
> Access Reporting Parameter" in "Set Reader Config" command. Let us
> suppose that the RNC has conveyed to the reader to send the report every
> inventory round. In the case of a premature termination of an inventory
> round due to "stop inventory", the reader would declare the round is
> over, and send the report back.
> 
> 
> >      1. Why does Access cmd and Inventory Cmd have both Antenna ID's? 
> >         Does the Inventory Antenna override the Access Antenna?! 
> A reader can have multiple antennas. Each antenna may be monitoring a
> different physical region of a facility, each requiring a different
> setting for inventory parameters (depending on the RF characteristics of
> the physical coverage area, tag population/mobility, tag protocols to
> inventory). 
> 
> Likewise, there may be different access operations to be performed by
> each of these antennas. For example, antenna 1 monitors Dock Door 1
> (DD1), antenna 2 monitors Dock Door 2 (DD2). For goods received at DD1,
> the business logic would like to read the user memory in tags that match
> pattern 123.*, and for goods shipped from DD2, the business logic would
> like to read user memory in tags that match pattern 456.*.
> 
> SLRRP provides a flexibility to set up inventory parameters and
> access-specs differently and separately for each antenna. 
> 
> No, inventory antenna does not override the access antenna.
> Inventory and access are decoupled from each other. 
> 
> Inventory is the method to read the tags in the field of view. SLRRP
> provides the interface to control how that inventory operation is
> performed by each antenna of the reader. 
> Access commands creates access-specs at the reader which is looked up
> during inventory rounds to determine if there is any additional
> tag-memory access operations to be performed.
> 
> There may be instances where there are access-specs created at the
> reader. The RNC may have sent an inventory command which sets up the
> reader to run 'forever' using the inventory-parameters; the reader in
> turn performs the singulation using the parameters without any
> subsequent tag-access operations and sends back the inventory report to
> the RNC.
> 
> 
> >      1. What if a stop Access is given in the middle of an Inventory
> >         cmd?  What happens?  Do the Access parameters "go away" in the
> >         middle of an inventory? 
> 
> Good question.
> 
> The deleted access-spec will stop taking effect from the next inventory
> round. 
> 
> Similarly, for a new access-spec, we have text in Section 3.4.9 that
> states that the new access-spec takes effect starting with the next
> inventory round.
> 
> 
> >      1. How do you know how many Inventory Access reports are coming
> >         (suppose a large report is fragmented into smaller pieces)? 
> > 
> We have not specified the format of the inventory access report in V01
> of the spec. It'll be addressed in the 02 version of the spec. There
> will be a bit in the message that indicates if its the last 'piece' of
> the report.
> 
> Thanks,
> /Krishna
> 
> 
> _______________________________________________
> Rfid mailing list
> Rfid@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/rfid


_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid