multichat client remoting issue - remoting

  • Thread starter Thread starter Tom
  • Start date Start date
T

Tom

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
 
When signing in, get the client to pass an interface to themselves to the server and have the server allocated an ID for the user (a GUID maybe?) and return it to the client as the result of the sign-in - think of it like a session ID. Now get the client to submit the session id with each new message. The server stores the user name, GUID and interface for each connected user. In fact you could dispense with the GUID and just pass the user name with each new message.

The server can call the clients back on the interface to deliver the messages from others.

For the server to call the client you may have firewall issues and the client must be listening on a port. Normally just getting the client to use 0 as the parameter to the channel constructor will be enough. This listens on a free port, the valuke of which will be passed to the server in the marshalling information for the interface

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<[email protected]>

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
 
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..
 
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
 
is there a way to use event delegate to do this ? it would seem to be much
easier than writing out a client interface class and keep track of it on the
server ?

Tom


Richard Blewett said:
When signing in, get the client to pass an interface to themselves to the
Click to expand...
server and have the server allocated an ID for the user (a GUID maybe?) and
return it to the client as the result of the sign-in - think of it like a
session ID. Now get the client to submit the session id with each new
message. The server stores the user name, GUID and interface for each
connected user. In fact you could dispense with the GUID and just pass the
user name with each new message.
The server can call the clients back on the interface to deliver the messages from others.

For the server to call the client you may have firewall issues and the
Click to expand...
client must be listening on a port. Normally just getting the client to use
0 as the parameter to the channel constructor will be enough. This listens
on a free port, the valuke of which will be passed to the server in the
marshalling information for the interface
 
I think you don't understand the question.. I want to send msg from userA to
userB its got nothing to do with authetication...
 
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
 
Back
Top