Re: not what I'm after
From: Nick Malik (nickmalik_at_hotmail.nospam.com)
Date: 10/12/04
- Next message: Dirk Reske: "shutting down a socketreceiving thread"
- Previous message: james: "Re: msi installer question"
- In reply to: Tom: "Re: not what I'm after"
- Next in thread: Richard Blewett [DevelopMentor]: "Re: multichat client remoting issue - remoting"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 12 Oct 2004 14:36:25 GMT
Hi Tom,
Users A, B, and C have to be listening to a port to get a message over that
port. Either that, or the message lives in storage on another machine until
the User A goes to pick it up, which is not what I expect you are looking
for.
So User A has to make a port available.
If you want User B to be able to start a conversation with User A, then User
A has to pass some information to a common point where User B knows to go
look for it.
That information has to contain enough information to contact User A. This
usually means: the IP address of User A, the port to use, and the protocol
to use. Since the IP Address of User A may change fairly often, this data
has to be fresh.
You also have the problem of proxy servers. If User A and User B have a
proxy server between then, then the proxy server actually "owns" the IP
address of one of the players, and has to be counted on to relay the message
(something I wouldn't count on, if I were you).
Will you be using an established protocol or are you writing your own?
If you use an established protocol, you can take advantage of the support
for that protocol built in to some firewalls and proxy servers. However,
your app will conflict with other apps using the same protocol, especially
if that protocol is tied to a specific port. If you want to avoid
conflicts, best to use an established protocol over a different port, but
you lose the support from the firewalls. It's a tradeoff.
If you are willing to go with simple SOAP messages, which is what you imply
with your original post on using remoting, you get some advantages and some
disadvantages. I don't know if it will work on XP Home edition or Windows
95/98 (no web server)... that's the disadvantage. On the other hand,
there's a great deal of support in .NET for this kind of thing.
A good book to help you to understand the ins and outs of .Net Remoting is
"Advanced .NET Remoting" by Ingo Rammer. I strongly suggest that picking up
a copy of this book will give you the groundwork that you need to use .NET
Remoting for solving this problem. Certainly, .NET remoting isn't the only
way to solve this problem. If you decide to go with direct network
programming, then I don't have a good book recommendation off the top of my
head (others may), and I would suggest that you google on ".net network
programming" to find useful articles.
Good luck,
--- Nick
"Tom" <tomgaomail@optushome.com.au> wrote in message
news:416bd9c3$0$10351$afc38c87@news.optusnet.com.au...
> I think you don't understand the question.. I want to send msg from userA
to
> userB its got nothing to do with authetication...
>
> "Lee Alexander" <lee@NoSpamPlease_Digita.com> wrote in message
> news:u$fyLwEsEHA.1816@TK2MSFTNGP09.phx.gbl...
> > When I wrote one to play around with remoting (a while ago) I had on the
> > server a SignOn and SignOff method that the client would call passing as
> one
> > of the parameters the URL of the client. This URL was used by the server
> as
> > a way of identifying a client and sending messages to it. I used
> > authentication to get the user name of the user on that client but you
> could
> > just pass the user name into the SignIn method if you want. Any
subsequent
> > calls to the server from a client would pass this URL as a way of
> > identifying who was sending the message. I added some extra little bits
> like
> > discovery of the server using mutlicast messages so the user didn't have
> to
> > type in the server address.
> >
> > HTH
> >
> > Regards
> > Lee
> >
> > "Tom" <tomgaomail@optushome.com.au> wrote in message
> > news:416bb0bf$0$20128$afc38c87@news.optusnet.com.au...
> > > I am not looking for who the user is...
> > >
> > > and third party is not the response I'm looking for. I want to write
it
> > > myself and I need direction on this..
> > >
> > >
> > > "Lee Alexander" <lee@NoSpamPlease_Digita.com> wrote in message
> > > news:ekhpz2DsEHA.736@tk2msftngp13.phx.gbl...
> > > > If your server is running under IIS then you can make use of
> > > authentication
> > > > to find out who the user is. Otherwise you will have to either buy a
> > third
> > > > party library or write your own. Here is an article that might help
if
> > > your
> > > > not running under IIS.
> > > >
> > > >
> > >
> >
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/remsspi.asp
> > > >
> > > > Regards
> > > > Lee
> > > >
> > > > "Tom" <tomgaomail@optushome.com.au> wrote in message
> > > > news:416b91a5$0$29780$afc38c87@news.optusnet.com.au...
> > > > > hi,
> > > > >
> > > > > I'm trying to write a multi client chat app using remoting.
however
> > atm,
> > > > I'm
> > > > > stuck when a userA tries to send userB a msg... say there're
userA,
> > > userB
> > > > > and userC. on the server side how do I know which user is userB
when
> I
> > > > > recieve message from userB ?
> > > > >
> > > > > what should the process be. I know I need to store a reference of
> the
> > > > > clients somehow on the server. but how can this be done ?
> > > > >
> > > > > thanks
> > > > > Tom
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
- Next message: Dirk Reske: "shutting down a socketreceiving thread"
- Previous message: james: "Re: msi installer question"
- In reply to: Tom: "Re: not what I'm after"
- Next in thread: Richard Blewett [DevelopMentor]: "Re: multichat client remoting issue - remoting"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
