# Reply client base on session id
**URL:** https://discourse.nodered.org/t/reply-client-base-on-session-id/2260
**Category:** General
**Created:** [14 August 2018 02:22 UTC](https://discourse.nodered.org/t/reply-client-base-on-session-id/2260 "2018-08-14T02:22:19Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@thiren](https://discourse.nodered.org/u/thiren)
#### Post date: [14 August 2018 02:22 UTC](https://discourse.nodered.org/t/reply-client-base-on-session-id/2260/1 "2018-08-14T02:22:19Z")
How to reply client base on client session id after the request payload go through few nodes??
I need some example flow nodes?
---
### Author:  [@shrickus](https://discourse.nodered.org/u/shrickus)
#### Post date: [14 August 2018 04:10 UTC](https://discourse.nodered.org/t/reply-client-base-on-session-id/2260/2 "2018-08-14T04:10:45Z")
That's a very general question -- it would help to see the relevant part of your flow...
Is this flow starting with an `http in` node? If so, just make sure that you end the flow with an `http response` node, and that you do not remove or modify the original `msg.res` field along the way.
---
### Author:  [@thiren](https://discourse.nodered.org/u/thiren)
#### Post date: [14 August 2018 05:54 UTC](https://discourse.nodered.org/t/reply-client-base-on-session-id/2260/3 "2018-08-14T05:54:08Z")
I'm using tcp in and out. Above are the flow.
---
### Author:  [@thiren](https://discourse.nodered.org/u/thiren)
#### Post date: [14 August 2018 06:17 UTC](https://discourse.nodered.org/t/reply-client-base-on-session-id/2260/4 "2018-08-14T06:17:44Z")
I already found my solution.
No matter what value you are going to reply to the client, just reply with "msg.payload", do not reply with any other massage when you build socket connection flow, Example for newbie:
DON'T : msg1.payload or \_ipadd.payload or any other var with .payload
DO : msg.payload
---
### Author:  [@shrickus](https://discourse.nodered.org/u/shrickus)
#### Post date: [14 August 2018 12:46 UTC](https://discourse.nodered.org/t/reply-client-base-on-session-id/2260/5 "2018-08-14T12:46:30Z")
Makes sense -- and probably for a similar reason as an http flow. Likely, there a client id field on the original msg object that needs to stay intact throughout the flow, so the `tcp out` node can know which client to respond to. If you put a `debug` node set to show the full msg object after the `tcp in` node, you can see how it works...