Log in

No account? Create an account

Previous Entry | Next Entry

If it's good enough for irc?

I've been... programming. more of my time has been diverted towards Neverwinter Nights thank I'd like to admit, but every *thinking* moment has been dedicated to figuring out a robust chat system.

I've been trying to wrap my head around getting real synchronicity and clean threading.

I've been dying to find examples of something done the way I'm doing it. To no avail.

IRC should be a good example of things, right?

But so far as I can tell, IRC is asynchronous in status replies. If you send a command and it doesn't work.... you may well get a "chat" message before getting the "error" message. Unlikely, but possible.

Is this really so horrible? It seems like it should be, my guts wrench... but... IRC is quite successful. It doesn't seem to be such a big deal.

I really want to do right by this system, though -- plain text yet computer decipherable replies are made to EVERY command, whether they worked or not and if not some message explaining why not... just in case such a thing should be trickled up for the enduser to see... so I'm worried about receiving a message inbetween a command being sent out and the reply to that command being returned.

of course, I could just add a state to say "queue messages until reply comes in"... or I could handle such things asynchronously, keeping track of the fact that I was expecting an answer to something and jumping back to that bit of code if/when the reply comes...

what I've been working on, though, is setting up TWO channels of conversation... opening two sockets for each client... and tying them together... it's a little ugly, but... it "feels" right. just not entirely, or I wouldn't be blathering about it here, hoping for a saviour to sweep down and bless me with The Right Way To Do It. Presuming there is a best answer... which is not necessarily a fair assumption.

I should be coding, not whining. I think I'll go to sleep.


( 5 comments — Leave a comment )
Oct. 18th, 2002 04:42 pm (UTC)
why not have each datagram start with a "1" if it's a system message, or a "0" if it's a user-level message?
Or something along those lines...
Oct. 18th, 2002 04:56 pm (UTC)
:blink: you look really different in your new userpic.


the issue (as I understand it, which... I'm really confusing myself and I suspect none of this matters at all...) boils down to:

send("MASS this is a message for everyone")
expect("+MASS mass message sent");

but if it's stuff on only one channel... then instead of getting what it expects, it might well get "MESS this is a message for everyone" instead... or a message from another user, or ...

the reason for the expect stage is that I want it to be able to receive, for instance...

-MASS admin priveleges required
-MASS unable to send to 1 or more recipients

the way IRC handles this, so far as I understand, is that it doesn't expect any reply from the server... and if the server wants to give the client an error message, it does that in its own thread, not in direct response to what was said...

I don't like any of the answers so far as I understand them. :(
Oct. 18th, 2002 07:05 pm (UTC)
Are you writing a client, server, or both?
This is the encrypted stuff you were dealing with earlier?

Can you not:
Have two threads running, and have a module that accepts all incoming traffic and bounces it to the appropriate thread?

IF incoming begins with "1" THEN hand off to server-message-parser
IF incoming beings with "0" THEN hand off to user-message-parser

Note, I'm not a coder...
just thinking of underlying logic.
Oct. 18th, 2002 09:25 pm (UTC)
writing both, and... yeah, in a perfect world this would be entirely related to all the encryption smack I was talking earlier. and ostensibly once I get this up and running, I'll put the encryption to work and do a new version. but this has to be up "ASAP", preferably by the end of the weekend.

Sorry I'm not explaining my problem better -- I suppose if I could explain it perfectly, I'd probably have an answer for myself. as it is, I'm actually doing it the less robust way in the hopes that I can wrap my mind around it better as such.

what I had before was... well, complicated. but the rub was at the "expect" bit -- it would sit and wait. there were enough threads that that wouldn't lock anything up... the server would respond to the client just fine. but if the server in one of its myriad threads responded with something other than was respected... I'm already *inside* the loop, expecting one specific thing... as opposed to trolling for ye olde message from the server. I'm... moving the "expect" business out/ignoring it, so responses from server only happen in one spot... means keeping more "state" information, essentially, leaving less of it intrinsic to the structure of the code.
Oct. 18th, 2002 07:06 pm (UTC)
... and my old pic is about a year old...
I was a skinny little fucker. (:
This one is from last weekend.
( 5 comments — Leave a comment )

Latest Month

February 2016


Page Summary

Powered by LiveJournal.com
Designed by chasethestars