Sending to the group instead.

On Sun, Jul 23, 2023 at 12:46 AM Eli Lindsey <e...@siliconsprawl.com> wrote:
>
> I’m taking a stab at answering, but I didn’t quite follow your intent and may 
> have misunderstood your question. Please let me know if that’s the case. :)
>
> I'm having a hard time putting it into my code. Specifically, how to handle 
> incoming new chats message and push to all web base clients. What's the 
> simplest solution for it?
>
>
> It’ll probably be easiest if you define what the client is/what protocol the 
> client speaks and work back from there. Skimming the code, it looks like your 
> demo is speaking http to web browsers and the chat example you’re interested 
> in merging is a custom protocol (a very simple one, “echo what’s received”) 
> on bare tcp. You have many options: if your clients are something like 
> netcat, you can define the protocol to initially be http with an html 
> response that then switches to tcp echo; if your clients are web browsers, 
> some strategies to consider (from least to most complicated) are periodic 
> polling, long polling, and a protocol that supports push out of the box like 
> WebTransport.
>
> If you want the simplest version that works in a web browser, I would write 
> it so that the user has to manually refresh (or click a button) to see new 
> messages. Once that works you could then look into how to make the client 
> pull new messages without a manual refresh, but that’s likely to be 
> client-side js and not server-side go, so may or may not be interesting 
> depending on what you’re wanting to learn from this exercise.

Ah, yeah, manual refreshing is simplest to do. Good idea!

> Note, to avoid user hitting refresh and lost all past conversation, I was 
> planning to store all of them, including the connect variable returned from 
> `net.Dial` into cookies. I know that there is a 4K size limit to total 
> cookies size, but that's OK with me for such a simplest chatting service, 
> which would add as minimum to the solution from ch8/chat as possible.
>
>
> I’m not entirely sure what you’re describing here, but carrying the net.Conn 
> in a cookie sounds odd. Could you say more?

Starting from
https://github.com/adonovan/gopl.io/blob/master/ch8/netcat3/netcat.go

Indeed, it is a custom protocol (a very simple one, “echo what’s
received”) on bare tcp. How it works on cli is that each client starts
their own cli client, having their own net.Conn for the whole
communication, and will get new messages from there.

Now, when shifting that onto a web service, where only one instance
would serve all different clients, the only thing *I can think of* is
to

- spinning up a new chatting client goroutine (mainly the quoted code
in OP) when a new user logs in, then there will be a new net.Conn for
the client
- since I'm only doing server side programming and one server needs to
serve different clients, the only way I can think of is to store their
own net.Conn in their own cookies to track individual status
- to avoid users hitting refresh and losing all past conversations, I
think I have to store the conversation (since login) in cookies as
well.

Hmm... on second thought, since I'm planning to let users do their
manual refreshing, maybe store the whole conversation on the server
and when refresh, it prints from the 1st line again might be another
option.

What would you think is the easiest thing to do here? Thanks!


> On Jul 22, 2023, at 11:26 PM, Tong Sun <suntong...@gmail.com> wrote:
>
> I know web based chatting service can be as complicated as possible, but I 
> want to build a web based chat server that is as simple as possible.
>
> And the chapter 8 of the book "The Go Programming Language" at
> https://github.com/adonovan/gopl.io/tree/master/ch8/chat
> seems to be a perfect starting point to learn the asynchronous web based chat 
> service building.
>
> I've built a whole (simplest) web service that support user login and logout, 
> at:
> https://github.com/suntong/lang/blob/master/lang/Go/src/net/HttpD/demo-redirect.go
> and was planning that the next logic steps would be to
>
> - incorporate the chat server as another goroutine besides my web server, and
> - add the chatting to my web service by spinning up a new chatting client 
> goroutine when a new user logs in.
>
> However, it is incorporating the chatting client into my web service that 
> made my head spinning none-stop. IE, for the following few lines of code from
> https://github.com/adonovan/gopl.io/blob/master/ch8/netcat3/netcat.go
>
> done := make(chan struct{})
> go func() {
> io.Copy(os.Stdout, conn) // NOTE: ignoring errors
> log.Println("done")
> done <- struct{}{} // signal the main goroutine
> }()
> mustCopy(conn, os.Stdin)
> conn.Close()
> <-done // wait for background goroutine to finish
>
> I'm having a hard time putting it into my code. Specifically, how to handle 
> incoming new chats message and push to all web base clients. What's the 
> simplest solution for it?
> Note, to avoid user hitting refresh and lost all past conversation, I was 
> planning to store all of them, including the connect variable returned from 
> `net.Dial` into cookies. I know that there is a 4K size limit to total 
> cookies size, but that's OK with me for such a simplest chatting service, 
> which would add as minimum to the solution from ch8/chat as possible.
>
> Anybody can help please?
>
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/e3327bc2-4f2f-4038-b38d-0c9794ec6235n%40googlegroups.com.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMmz1Ofwc1DY7U6Xbzq04KmD4%3DJaP632ZKP8N_NW7jwEnXTraQ%40mail.gmail.com.

Reply via email to