Hello All again.
Thank kindly Daniel for your email. I didn't think anyone would really
reply to my thread. Your indepth discussion was a godsend.
Firstly, i'm going to babble a bit, so I appologise if
1) This email is long
2) My solution is really obvious and dumb, or wrong.
I read over it a couple of times, and I kept thinking about the
following concept / statement you mentioned in my proposal.
>> So we buffer the text.
>> So we tack #2 onto the end of the buffer.
>> We tack that onto the end of the buffer ...
And i kept thinking, yeah .. that all good, but i failed to mention that
my RECIEVING DATA is a mix of STRINGS / TEXT and XML TEXT / DATA.
To me, this ment -> *when* do i buffer?
And then your entire email made sence with regards to my blond, lame
~protocol~ i'm using. [I'm not sure if PROTOCOL is the correct word, but
anyway...]
With my version of the stock code, i've create a new STRIPPED DOWN
version of struct descriptor_data *d;
I've called it struct client_descriptor_data *cd;
It basically just handles text in and out and holds a few extra char *'s
(username ....). I didn't want to recycle the huge descriptor_data becuase
it held a lot of wasted structs, char *'s, this that etc... which i would
never be using for my unique MUD-CLIENT SOFTWARE.
This new client descriptor sends text [SEND_TO_CLIENT_Q(..)] in the
format [CLIENT_OK || CLIENT_ERROR] <text>.
the CLIENT_OK || CLIENT_ERROR are MUD side states.
An Example of a failed client login would be :-
SEND_TO_CLIENT_Q ("[CLIENT_ERROR] Name Error :: Invalid Characters
detected.", cd);
I'm sorry if this is dragging on, so i'll explain my point with regard to
how i know when to buffer and when NOT to buffer...
If i *ASSUME / KNOW* that i'm reciving information from the mud in the
following format :- <STATUS> <TEXT> I can then assume that if the current
packet recieved does NOT contain a <STATUS>, i just ~BUFFER~ it.
I'm using the TCP stack, so i assume that all my packets / text are
recieved in ORDER..
>> The only time you should need packet numbering schemes is when you're
using a protocol that doesn't guarantee the transmission order of the data.
So there you have it!
Thank you so much Daniel for helping me :)
Sincerly: Justin
-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
Everan Roseblade Everan@EternalVisions.com
Eternal Visions Mud eternalvisions.com:1200 www.eternalvisions.com
-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/05/01 PST