Forum Discussion
NimbostratusPassing around JSON
A new app is being developed that uses JSON and http among servers providing servers. What would I use to persist connections to the same node other than source persistence?
Thanks!
8 Replies
- Kevin_Stewart
Employee
Persistence depends almost entirely on the capabilities of the client. If the client can handle cookies, then that is the easiest option. Otherwise if there's something unique in the JSON data (a unique identifier), then you could use universal persistence and an iRule. 
mraful_64014Hey, thanks. That's what I thought. If the developers don't put anything in the headers to make it unique and/or their clients down look at it, I am up the crick w/out a paddle . What if all their communications had to be https as opposed to http? Then I could use the SSL sesssion id, correct?
- Kevin_StewartWell that's an interesting question, and it would still depend mostly on the client. Most modern browsers will force SSL renegotiation after some period of time. If you're building your own client, and you don't force renegotiation, then you could get away with it. It isn't the most secure thing in the world, but many agent-based clients also do this (Citrix Receiver for example). Cookies are still your best bet if the clients can handle them.
- mraful_64014
Nope, no browswers at this point the app execution. The user comes in from a dmz., goes to an app server, the app server makes requests via http with Content-type: application/json to other servers, which are returned to the app server and finally sent back to the user. So, on the back end, no clients. Nothing on which to persist. Pretty wild, eh?
- Kevin_StewartServer-to-server communication isn't too unusual, but it definitely presents issues that a client wouldn't have. Here are some additional thoughts:
1. Are the server-to-server requests finite, or do they span multiple TCP sessions? If they all live inside a single TCP session then you really don't have to worry about persistence.
2. Is there any form of persistence of the client side, perhaps a cookie that the browser sends to the app server? If so you could potentially use that value to map persistence. - mraful_64014
Wow.... you just raised a great point. As far as I know, they are finite TCP sessions. In other words (if I understand your point correctly), request and receive data; NOT request data, receive data, close connection, process some of the data, open new connection to get more data. If so, persistence is not needed. Correct?
There is a cookie but that is done at the top layer F5, the bottom layer F5 is for the distributed services. This has to be persistent. Long story.
- Kevin_StewartI guess the bigger question is where and why do you need persistence. If the data calls are finite, or rather "atomic" (make request, get response, done), and each request/response pair isn't dependent on other request/response pairs, then maybe persistence isn't needed.
Otherwise, if I can assume that the clients talk to an external F5, which then talks to an internal F5, which then load balances to the distributed services, and you need persistence at the internal F5 based on a specific client, you would want to pass something from the client through to the internal F5 to use as a persistence token. - mraful_64014
from what I understand the app does not need to save any state information and if it did, I presume it would be up the developers to implement something (for example, instead of JSON they useed soap and put somehting in soap header) that I could use to persist on for the server-to-server communication. In fact, in one part of the application they do not do this at all yet the connection is not finit and they have hard coded the ip address of another server in the apache mod_proxy configuration.
