Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Using TServerSocket with multiple clients

824 views
Skip to first unread message

John

unread,
Apr 15, 2002, 4:57:15 AM4/15/02
to

I am trying to get to grips with TServerSocket. I will have
several (up to 30, say) clients connecting to a single
ServerSocket. From time to time, Server will need to send data
asynchronously to one or more Client.

Question: how do I address outbound data from Server to a
specific client. I can see how I determine which Client has sent
data to Server (e.g. reading Socket.RemoteAddress) but I can't find how I address asynchronous outbound from Server.

Thanks.

John

Paul Gertzen

unread,
Apr 15, 2002, 7:15:44 AM4/15/02
to
Look at at ServerSocket.Socket.Connections. (See help on TServerWinSocket).
This is an array of all the connected client sockets.

Paul

"John" <g3...@aol.com> wrote in message news:3cba95eb_1@dnews...

John

unread,
Apr 15, 2002, 10:11:00 AM4/15/02
to

Hi Paul,

Thanks for the reply. I understand how to find what clients
are connected to the Server. What I can't seem to find is how I
address data *outbound* from the Server to a specific Client.

Any assistance appreciated!

Thanks

John

Peter Below (TeamB)

unread,
Apr 15, 2002, 1:30:45 PM4/15/02
to
In article <3cbadf74$1_2@dnews>, John wrote:
> Thanks for the reply. I understand how to find what clients
> are connected to the Server. What I can't seem to find is how I
> address data *outbound* from the Server to a specific Client.

John, you may want to ask in delphi.internet.winsock.

As i understand sockets (which is only superficially) it is *always* the
client that starts a conversation. It sends something to the server, then
waits for a reply (optionally). It will not wait for a conversation
initialized by the server (even if there is an existing connection). So, to be
able to have a "backlink" you need a TServerSocket on the client side as well
the listens for connects from a TClientsocket the server creates for the
backlink.

--
Peter Below (TeamB)
Use the newsgroup archives :
http://www.mers.com/searchsite.html
http://www.tamaracka.com/search.htm
http://groups.google.com
http://www.prolix.be


Andy M.

unread,
Apr 15, 2002, 4:37:14 PM4/15/02
to
Hmm, not quite correct...

Most protocols may work that way, but generally, clients and serve are
alike, meaning, both can send and receive using the same methods. The only
difference is, that a client connects to a port and a server listens to a
port. If the connection is established, you can do the communication in both
ways.

For TServerSocket use:

ServerSocket1.Connections[I].SendText('Hello client...'),

where "I" describes the client you want to use...


--
Kyoto Now !


John

unread,
Apr 15, 2002, 5:57:55 PM4/15/02
to

Andy,

I think you just gave me the clue I needed! Many thanks.

John.

Paul Gertzen

unread,
Apr 16, 2002, 5:05:29 AM4/16/02
to
The only problem with sendtext is that it can only send text and just like
all tcp sends - it may not send everything in 1 go. What I do is create a
class for the client connection that contains how much data to send, how
much has been sent, and the buffer that needs to be sent. I then attach this
class to the socket.data pointer. When the onclientwrite/read/etc.. events
get called, they supply the socket parameter which is the clientsocket which
is sending/receiving. I then retrieve the class from socket.data, and
send/read the next piece of data and update my bytesread/sent. When all the
data is sent/read, I process it and free the class. This way you can keep
seperate information for each attached socket (ie. no globals).

I can send you an example if you wish. The conversation is initiated by the
client in this example but you'll get the idea.

Paul

"John" <g3...@aol.com> wrote in message news:3cbb4ce3$1_2@dnews...

Andy M.

unread,
Apr 16, 2002, 6:00:30 AM4/16/02
to
If it's really about sending much data, I'd prefer blocking sockets
anyway...

Andy

--
Kyoto Now !


Paul Gertzen

unread,
Apr 16, 2002, 7:10:29 AM4/16/02
to
Definately my preference too, client blocking and server threadblocking.
Synchronous code is much easier to read, no events firing all over the place
whenever they please :)

Paul

"Andy M." <andy.m...@gmx.net> wrote in message news:3cbbf65f_1@dnews...

0 new messages