Custom router payload

#1

Hi,

I think I may have broached this topic before, but I’m seeing the use-case recur multiple times so I’m going to have another crack, maybe with a better explanation.

When tracking session related information, I’m finding it doesn’t make sense to do this anywhere other than inside a crossbar module, it just introduces too much latency.

In my specific use-cases (I’m sure there are others too), I’m tracking the IP address of the incoming connection, and the oAuth2 ticket issued by Google as part of the ticket-based custom authentication.

(so these exist essentially inside the router)

So I have;

  • Incoming packet -> Authenticate -> Store IP and Ticket
  • RPC Call -> routed to Microservice
  • Microservice -> RPC Call -> Router (to recover the IP and Ticket)
  • Microservice -> Returns result

This adds a great deal of unwanted latency / inefficiency.

The solution I’ve implemented is to add and RPC stub to the router, have the stub add the IP and Ticket, then call the final RPC routine with the extended message.

Incoming packet -> Authenticate -> Store IP and Ticket

  • RPC Call -> Router
  • Add IP and Ticket to Message
  • RPC Call from Router to Microservice
  • Microservice -> Returns result
  • Router -> Returns result

This is better in terms of performance, but in terms of design and manageability it’s horrible.

What would fix this properly, would be to allow the router to ‘amend’ the packet as part of the routing process, i.e. append the additional fields as the message passes through.

For me the ideal place for this would be to expose the message in the custom authorization call, so once the call has been Ok’d, any additional data can be tacked on at that point.

For example;

def function(self, session, uri, action, details=None):
“”“Authorize individual calls”""
return {‘allow’: True, ‘disclose’: True}

``

Might become;

def function(self, session, uri, action, details=None):
“”“Authorize individual calls”""
session_data = {‘ip’: self.ip[session], ‘ticket’: self.ticket[session]}
return {‘allow’: True, ‘disclose’: True, ‘payload’: session_data}

``

I know you can get the IP with a meta call, but if you’re taking thousands of incoming requests per second, having every call make a further

internal RPC call just to get the IP address does have a substantial impact. (my fix above yields x10 improvement on latency)

Alternatively, does this feature already exist, or am I missing a better way of doing it?

tia

Gareth.

0 Likes