Sorry if I did not make myself clear, I am not a native English speaker, so
please excuese me for grammatical incorrect sentences and so on.
What I want is actually OPPOSITE of seperating the people, I want the two
ports to have seperate programs, and thus seperate functions, doing seperate
stuff. While the players can SEE each other (not seperate here, as opposed
to what you said), interact with each other, walk in the same rooms, and
talk to each other. Maybe my former messages made it look like I wanted to
seperate people, making two lists for who and stuff is easy to do, but my
point is to combine the two people. That is why I wanted to share memory
allocations, so I could, for example only, build on one port, with IMMEDIATE
result on the player port. Or I can have a stable running version on one
port, and a testing version (obviously, when testing new codes, it must be
another program) listening on a different port, while able to walk on the
same ground.
This might all seem too idealistic, or rather, naive, but if it is possible,
I am willing to try. (How many high schoolers does socket programming
anyways? Since I spent the time in learning socket programming, I don't see
why I cannot spend time to learn other interprocess commmunication methods.)
Don't get me wrong, I appreciate your responses, but it prompted me to make
anotehr clarification on my purpose, that's all.
As an illustration. I make class PC a derived from class CH, and I also make
class MOB a derived from class CH. So if I have a linked list of CH's, when
I call the CH::show_status( ), if I write the function so that it looks like
if( this->type == CHTYPE_PC ) { blah } else { blah }
and a lot of them, shouldn't we think that PC and MOB know how to show their
status themselves? That's where polymorphism comes in, and by making
CH::show_status( ) virtual, we can succeed in calling MOB's or PC's own
show_status( ) function. I understand this has some overhead, but I would
say it is reasonable. (Anyway the point is not the above, I am just making
an analogy.) So if I make two ports listen, and once connects, I put in from
the port 2300, I initialize the `this->test' to be TEST_NO, and from 2301
TEST_YES. And whever they type the commands that I am testing, I would
perform `if( this->test == TEST_NO) return' to keep people from the normal
port from testing the new commands, the same question arises with the
CH::show_status( ) thing. Couldn't each `port' (I know that ports don't
actually decide, but you get what I am trying to say) decide on what they
will react to the incomming text? Couldn't one port (again, its not the port
that does things) just _know_ what to do without checking if the PC is
actually connected through which port? So I wanted to make the two programs
seperate, maybe not for the benefit of my mud, but as a practice of
programming.
Thanks for your time. :]
Htam
----- Original Message -----
From: "Dale Kingston" <[EMAIL PROTECTED]>
To: "Jed Yang" <[EMAIL PROTECTED]>; <[email protected]>
Sent: Tuesday, September 09, 2003 9:48 AM
Subject: Re: Snippet/Walkthrough for making a mud listen on multiple ports .
> Their not going to beable to share memory, So what your going to have to
do,
> is have the one connect to the other, and pass the information back and
> forth between each other.
>
> Where as I mentioned this before, it would be much wiser if you used 1
> program, and 2 ports. And then you just throw in some code to have it
> seperate the people.... Or you could take it a step farther, make two
linked
> lists for descriptors, and two linked lists for char's. And then run
through
> the mud that way.
>
> Two programs sharing data, I think is a little more complicated then a
High
> Schooler is probably willing to sit through and do.... And it's alot of
> extra work, when you can get 1 program that does the exact same thing,
much
> easier.
>
>
> ----- Original Message -----
> From: "Jed Yang" <[EMAIL PROTECTED]>
> To: "Dale Kingston" <[EMAIL PROTECTED]>; <[email protected]>
> Sent: Tuesday, September 09, 2003 10:36 AM
> Subject: Re: Snippet/Walkthrough for making a mud listen on multiple ports
.
>
>
> > Yes, I used that exact guide for my knowledge on socket programming as
> well,
> > but what I am after now is for TWO programs to listen on their
respective
> > ports, while sharing the same data.
> >
> > Htam
> > ----- Original Message -----
> > From: "Dale Kingston" <[EMAIL PROTECTED]>
> > To: "Jed Yang" <[EMAIL PROTECTED]>; <[email protected]>
> > Sent: Tuesday, September 09, 2003 9:37 AM
> > Subject: Re: Snippet/Walkthrough for making a mud listen on multiple
ports
> .
> >
> >
> > > Using a thing called a search engine one runs accross several websites
> > that
> > > are willing to teach you. This one I found worked nicly for me when I
> was
> > > getting my mud to open another port.
> > >
> > > http://www.ecst.csuchico.edu/~beej/guide/net/
> > >
> > > ----- Original Message -----
> > > From: "Jed Yang" <[EMAIL PROTECTED]>
> > > To: "Jason Gauthier" <[EMAIL PROTECTED]>; <[email protected]>
> > > Sent: Tuesday, September 09, 2003 10:26 AM
> > > Subject: Re: Snippet/Walkthrough for making a mud listen on multiple
> ports
> > .
> > >
> > >
> > > > I will admit right away that I have no knowledge on shared memory.
> > > > (I am a high schooler, by the way, and most of us do not know a lot
> > about
> > > > programming yet, so please bear with me.)
> > > > Is there any specific books or websites that you would recommend on
> the
> > > said
> > > > subject? I always like to learn it myself and do it, rather than
just
> > use
> > > > someone else's snippet; so I would prefer a website that teaches
this
> > > > subject, not a code snippet that already works. (But any reply is
> > welcome,
> > > > since I can always learn from a code snippet, too; that is how I
> learned
> > > > some coding techniques, by reading the ROM code.)
> > > >
> > > > Sincerely,
> > > >
> > > > Htam
> > > > ----- Original Message -----
> > > > From: "Jason Gauthier" <[EMAIL PROTECTED]>
> > > > To: "Jed Yang" <[EMAIL PROTECTED]>; <[email protected]>
> > > > Sent: Tuesday, September 09, 2003 5:32 AM
> > > > Subject: RE: Snippet/Walkthrough for making a mud listen on multiple
> > ports
> > > .
> > > >
> > > >
> > > > > I'm sorry, I missed this message.
> > > > >
> > > > > One idea could be to create a shared memory location for
everything
> > > > loaded.
> > > > > This would make one running copy of the mud depend on the other.
> > > > >
> > > > > The second copy would then connect to those resources instead of
> > loading
> > > > > it's own.
> > > > >
> > > > > Players could converse across muds the same way, or using another
> form
> > > of
> > > > > IPC.
> > > > >
> > > > > It would be a time consuming task, but if you understand shared
> > memory,
> > > > that
> > > > > part shouldn't be too hard.
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jed Yang [mailto:[EMAIL PROTECTED]
> > > > > > Sent: Thursday, September 04, 2003 12:11 AM
> > > > > > To: [email protected]
> > > > > > Subject: Re: Snippet/Walkthrough for making a mud listen on
> > > > > > multiple ports .
> > > > > >
> > > > > > I am not using a ROM mud, but I started with it.
> > > > > > The current mud that I am working on, I also used polling for
> > > > > > connections.
> > > > > > (You could not really call mine a mud yet since you could not
> > > > > > do anything on
> > > > > > it.)
> > > > > > When I wanted to open a different port, the simple way of
> > > > > > doing it as Simmons described occured to me, and it does not
> > > > > > seem hard.
> > > > > > But I have one question.
> > > > > > If I do it this way, it is basically one program running
> > > > > > listening on two ports.
> > > > > > This is NOT what I want.
> > > > > > If I open the mud twice on different ports, then it will be
> > > > > > two programs running, that will cause my users on the two
> > > > > > different ports non-interactive.
> > > > > > What I want is two programs running yet able to communicate.
> > > > > > One way I thought of is making the two programs connect to
> > > > > > each other using peer to peer (or just server-client) TCP/IP
> > > > > > connection on the local machine.
> > > > > > Yet this will restrain my communications to be only of text.
> > > > > > (Or maybe not?) If, for instance, I want all the wiz to only
> > > > > > get wiz power on the wiz-port, yet able to talk to other
> > > > > > regular players, it seems easy to just craft up a small
> > > > > > protocol and do it. But if I want to alter user information,
> > > > > > dynamically alter rooms, mobs, and objects, it would seems
> > > > > > like I need to write a LOT of code on both sides, one saying
> > > > > > (of course in less verbose
> > > > > > sense) "I will change room vnum 387 exit 3 from whatever to
> > > > > > room 386". And this side that actually have the rooms is
> > > > > > memory will answer "Sorry room 386 not found" and the
> > > > > > wiz-side will send a note to the mistaken wiz. If I were to
> > > > > > let the wiz move around, I would have to do every single
> > > > > > thing like this.
> > > > > > Or another alternative is to send "Htam slay foo" from
> > > > > > wiz-side to the normal-side, and let the normal-side do
> > > > > > interp( get_char("Htam"), "slay foo", TRUE/*indicating having
> > > > > > wiz power*/ ) or whatever ROM is using (I kind of forgot.)
> > > > > > This will just cause the wiz-side to be a intermediate tunnel.
> > > > > > This is totally functional, but also totally useless, since
> > > > > > the marking of power can easily be done by setting a flag
> > > > > > when accept()'ing the different ports.
> > > > > > So having thrown out some solutions that I am not looking
> > > > > > for, I hope to get some feedback of other ways of doing this.
> > > > > > As a final note, I will expose my reason of doing this. I am
> > > > > > a Taiwanese and some of my friends only speak English and
> > > > > > some only speak Chinese (ya, ya, they should learn English,)
> > > > > > so my mud is a bilingual mud. Every time I sent them a
> > > > > > message (from the system, not a `tell'), I will check for
> > > > > > what language they opted for and send them that version.
> > > > > > (With a single function call like, bprintf( vch, "%s english
> > > > > > message here.\n\r", "%s chinese message here.\n\r", ch->name
> > > > > > ), which will do the check everytime.) Now I want to just
> > > > > > simply make my mud compile into English only or Chinese only
> > > > > > by a single macro at the top, and then I will have two
> > > > > > versions that does not perform this check every single
> > > > > > send_to_char's, but now if I run one on port 2300 another on
> > > > > > 2301, they will obviously be two seperate worlds. I hope to
> > > > > > make them walk on the same soil. Just a crazy thought.
> > > > > > Any ideas are welcome.
> > > > > >
> > > > > > Htam
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Chad Simmons" <[EMAIL PROTECTED]>
> > > > > > To: "Jason Gauthier" <[EMAIL PROTECTED]>
> > > > > > Cc: <[email protected]>
> > > > > > Sent: Tuesday, September 02, 2003 5:02 PM
> > > > > > Subject: RE: Snippet/Walkthrough for making a mud listen on
> > > > > > multiple ports .
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > --- Jason Gauthier <[EMAIL PROTECTED]> wrote:
> > > > > > > > I have a good grasp of network programming (Have written
> > > > > > several of my
> > > > > > own
> > > > > > > > cross platform mini web-servers, in fact).
> > > > > > > >
> > > > > > > > I was looking to save myself from inventing the wheel,
> actually.
> > > > > > > > I found a web server snippet from somewhere and ganked the
> stuff
> > I
> > > > > > needed.
> > > > > > >
> > > > > > >
> > > > > > > So, having written your own web servers, you didn't realize
> > > > > > that all you
> > > > > > needed
> > > > > > > to do was bind to another sockaddr, listen on the socket,
> > > > > > and add the file
> > > > > > > descriptor to your incoming fd_set? Seems fairly trivial to
me.
> > > > > > >
> > > > > > > Or were you asking specifically about getting the mud to
> > > > > > respond to the
> > > > > > http
> > > > > > > protocol?
> > > > > > >
> > > > > > >
> > > > > > > ~Kender
> > > > > > >
> > > > > > > =====
> > > > > > > -----BEGIN GEEK CODE BLOCK-----
> > > > > > > Version 3.1
> > > > > > > GCS/L/C/O d-(+) s++: a-- C+++$>++++ UBLS++++$
> > > > > > > P+++(--)$ L+++>++++ E--- W+>++$ N !o K? w(--) !O
> > > > > > > M- !V PS+ PE(++) Y+ PGP->+ t+ 5 X+() R(+) tv+@
> > > > > > > b++(+++) !DI+++ D G(-) e>+++$ h---() r+++ y+++
> > > > > > > ------END GEEK CODE BLOCK------
> > > > > > >
> > > > > > > __________________________________
> > > > > > > Do you Yahoo!?
> > > > > > > Yahoo! SiteBuilder - Free, easy-to-use web site design
software
> > > > > > > http://sitebuilder.yahoo.com
> > > > > > >
> > > > > > > --
> > > > > > > ROM mailing list
> > > > > > > [email protected]
> > > > > > > http://www.rom.org/cgi-bin/mailman/listinfo/rom
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > ROM mailing list
> > > > > > [email protected]
> > > > > > http://www.rom.org/cgi-bin/mailman/listinfo/rom
> > > > > >
> > > > >
> > > > > --
> > > > > ROM mailing list
> > > > > [email protected]
> > > > > http://www.rom.org/cgi-bin/mailman/listinfo/rom
> > > >
> > > >
> > > > --
> > > > ROM mailing list
> > > > [email protected]
> > > > http://www.rom.org/cgi-bin/mailman/listinfo/rom
> > > >
> > >
> >
> >
> > --
> > ROM mailing list
> > [email protected]
> > http://www.rom.org/cgi-bin/mailman/listinfo/rom
> >
>
