These are chat archives for fanout/pushpin

5th
Jan 2019
David Frey
@frey1esm
Jan 05 21:10
@jkarneges What would be to recommended transport protocols for a platform that uses mobile apps and websites utilizing chat/instant messaging, notifications, and other realtime messaging? SSE seems recommended for mobile (on fanout.io) but it's one-way.
Justin Karneges
@jkarneges
Jan 05 22:45
Hi @frey1esm , depends on your taste. If you're already familiar with using HTTP to GET/POST then sending data from client->server is solved, and SSE is needed only for server->client
alternatively you could use WebSockets. either will provide equivalent realtime delivery
David Frey
@frey1esm
Jan 05 22:50
Will pushpin convert an incoming publish message (over 5561) into an SSE?
in other words, how should the POST be formated on a given channel to be received in realtime via SSE clients?
Justin Karneges
@jkarneges
Jan 05 22:52
first, make sure the initial response from the server sets Content-Type: text/event-stream
and publish content like event: message\ndata: hello world\n\n
technically pushpin has no direct awareness of SSE. you simply use its HTTP streaming transport and provide the correct bytes
David Frey
@frey1esm
Jan 05 22:59
where does channel get selected?
Justin Karneges
@jkarneges
Jan 05 23:00
in the Grip-Channel headers sent in the server response
David Frey
@frey1esm
Jan 05 23:01
I mean, when I publish a POST tp http://localhost:5561/publish
Justin Karneges
@jkarneges
Jan 05 23:01
oh sorry, that earlier content was abbreviated
full content would be something like {"channel":"foo","formats":{"http-stream":{"content":"event: message\ndata: hello world\n\n"}}}
David Frey
@frey1esm
Jan 05 23:14
perfect - I'll give that a go. I already have SSE working in my flutter app so I'm anxious to see how far I can take this with our current project. I think you have a significant potential in that area (flutter) as not many of the commercial pub/sub providers are excited yet about flutter apps.
Justin Karneges
@jkarneges
Jan 05 23:34
Hi @picarsite , I think the behavior is correct. the goal of truncate is to retain the trustworthy parts, which will be rightmost, and you should know how many parts there would be based on your architecture (e.g. if there's a load balancer and then pushpin, you could do truncate:1 to ignore any potentially spoofed values provided by the client)
the truncate feature is not meant to be a way to trim the header so that only the single leftmost IP remains. hopefully your backend is able to parse the X-Forwarded-For and interpret the leftmost IP as the client IP