Working on my own IRC Client, some questions on how protocol/server behaves. reddit / irc ---------------------------------------------------------------------- redfire333 · 2017-04-13 18:27 Hey all, not sure if there is the right place for these kind of questions but here goes. When I join a channel, I get multiple responses from IRC server after I have sent the `JOIN` command. They occur in this order: -Server repeats/verifies JOIN command -Server sends channel topic -Server sends list of users in the joined channel (which can sometime be sent in chunks, due to message size limitation on IRC). First question: is that flow correct? Second question: Am I guaranteed that server will send everything needed before more commands are sent. (e.g. If I `JOIN` a channel, then someone happens to send a `PRIVMSG` before the complete `JOIN` response is completed, will server finish the `JOIN` before sending the `PRIVMSG`) I hope that makes sense! Thanks ---------------------------------------------------------------------- rdv_ · 2017-04-13 18:37 it is queued. you can send the commands immediately; it's best to send them in the same packet though like "JOIN #CHAN1,#chan2,#chan3"\r\n\"PRIVMSG #CHAN1,#chan2,#chan3 :Hello!"\n ---------------------------------------------------------------------- redfire333 · 2017-04-13 18:41 My question is in regards to the server Response/Input. Calling the `JOIN` command results in ~3 different responses, all related the the channel I join. Will the IRC server complete all of `JOIN` responses before sending more Commands to the client? ---------------------------------------------------------------------- A-UNDERSCORE-D · 2017-04-13 18:46 That would depend on the IRCd. It may be better to assume that you'll get them out of order and have a place for the messages to go ---------------------------------------------------------------------- rdv_ · 2017-04-13 18:55 Yes. It comes in order of events, so the order of the commands you sent. It's predictable; but it's not needed as the channel names, and user names etc are all sent in IRCd replies... so you can get them out of order and be fine. ---------------------------------------------------------------------- wosmo · 2017-04-13 19:00 I don't believe there's any guarantees there at all. I believe you're supposed to handle each message separately. Example scenarios: You try to join a channel you're banned from, or which requires an invite or password, or is limited, etc. You send a JOIN, you don't get a JOIN back. * You try to join a channel and are redirected to another instead (this is used a lot on freenode). So, eg, you send JOIN #ubuntu, and receive a reply JOIN #ubuntu-unregged. * The server has a default channel set, you connect to the server, and without sending any JOIN messages, you receive a "JOIN #lobby" reply. * You "JOIN #x,#y,#z" and receive three JOIN replies back. * And a fun one - you send "JOIN 0" and receive PART's back. (joining zero is a shortcut to part every channel) So, what you should be doing is sending a join message ... and then doing nothing. If you receive a JOIN reply, you should act on it. But this should be stateless - the JOIN reply may not be for the same channel you sent a join message for, or you may not have sent it at all. Similarly, you'll get the userlist any time you send NAMES, not just when you join a channel. You'll be sent the TOPIC reply when a user changes the topic, not just when you join a channel. so these replies should be handled stateless - that is, when you receive this message, you handle them. What requests the client made leading up to them is irrelevant, as it may not be the client that initiated the reply. What I mean is .. a client shouldn't going "I've done X, now I'm expecting X,Y,Z back". You simply service replies as they come. So if you receive "TOPIC #foo blah blah blah", you update #foo's topic to display 'blah blah blah'. There should be no need to be in a state where "I've send a JOIN, so I'm expecting a TOPIC". "I've sent a TOPIC, so I'm expecting a TOPIC". Just handle TOPIC properly when you receive it, and it should all fall into place. ---------------------------------------------------------------------- redfire333 · 2017-04-13 20:20 Awesome. Thank you! This is what I needed. Side question. I've read in Stackoverflow that using the NAMES command doesn't necessarily send the complete list of users. Is that true? ---------------------------------------------------------------------- CannedDeath · 2017-04-14 02:47 If you're not in the channel and the channel isn't +s, then I don't think it shows users who have usermode +i. And, for ircds that implement some sort of "auditorium" mode, it might not list any user who hasn't spoken or isn't voiced. Same with WHO. ---------------------------------------------------------------------- jawshthedark · 2017-04-14 17:50 I think you should work on the RAW codes. As far as I'm aware that's where it's at lol. ---------------------------------------------------------------------- Saber_UK · 2017-04-15 13:49 > And a fun one - you send "JOIN 0" and receive PART's back. (joining zero is a shortcut to part every channel) This is not widely supported behaviour. We (InspIRCd) do not support it because its mostly used for abuse ("free movies if you /join #0,0"). ---------------------------------------------------------------------- wosmo · 2017-04-15 15:27 Yeah there's a lot in the RFC that didn't survive (e.g., privmsg \*@\*.edu ....) I think it's still a valid edge-case when considering what replies you might expect though. Or at the very least, a lesson in not always getting the numeric you anticipated.