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 > > >
