Matthew,

A TCP/IP session like this needs one or more client sockets at one end, and
a server socket at the other end.
The docs are a bit obscure and we had to rely on several sources of
information including the D5 Developers guide chapter on socket programming
before we could figure it all out.

If I remember correctly, the SendStream method is simply another way to pump
data down the TCP/IP "pipe" represented by the connection. At the other end
the data arrives as a stream regardless of how you send it. The OnRead event
fires every time a chunk of data arrives, and you copy it from the buffer
and deal with it.

See the help for TCustomSocket.OnRead for more info on this. There's a
gotcha in there.

We were primarily interested in sending a constant stream of files to a
server in China, so our protocols were based on sending and receiving chunks
of data of known size. However the process should be very similar. If you
need example code let me know.

Cheers,
Simon.

----- Original Message -----
From: Matthew Comb <[EMAIL PROTECTED]>
To: Multiple recipients of list delphi <[EMAIL PROTECTED]>
Sent: 08 May, 2000 4:15 PM
Subject: Re: [DUG]: Sockets..


Nic thanks... I started programming something with clientsocket and
serversocket.. the ones built into Delphi but I couldn't work out how to
receive a stream using the built in events... you can go.

clientsocket.socket.sendtext -> socket.receivetext in onread

but how do you
receive:

clientsocket.socket.sendstream

and how do you detect which type of data is being sent through?

Any ideas?

Matt.


----- Original Message -----
From: "Nic Wise" <[EMAIL PROTECTED]>
To: "Multiple recipients of list delphi" <[EMAIL PROTECTED]>
Sent: Monday, May 08, 2000 3:19 PM
Subject: RE: [DUG]: Sockets..


> > Hi people, just a follow up to my earlier post.
> >
> > What is the best connection method (set of components?) using TCP\IP (or
> > not??)
>
> No need to step outside of the IP family, and as _everyone_ uses it these
> days (that arn't running on a default 95 install)
>
>
> > That can do the following.
> >
> >     1. send text in both directions.
>
> TCP works, UDP would also work. I think its synchronous tho - only one way
> at a time, tho I'm not sure why I think that :)
>
> >     2. send streams in both directions.
>
> UDP would be the best idea, I think. Depends if:
> a) the packets need to come in inorder. (yes = tcp, no = udp)
> b) the packets MUST GET THERE or its all over(yes=tcp, no = udp)
> c) a massive level of performance is needed (yes = udp, no = tcp)
> d) broadcast is needed (yes = UDP or TCP multicast(ouch), no = either one)
>
> TCP/IP is reliable, point to point, connection-oriented protocol. You
bring
> up a connection, send data, receive data (etc), and disconnect. the server
> then goes back to listening (well, it kinda was before). It is generally
> synchronous (tho windows allows you to use call-backs).
>
> UDP/IP is not reliable, is broadcast or point-to-point, and its
> data-gram/packet oriented. You get the IP and port of the remote machine
and
> send a packet. Thats it. No reponse packet, no nothing. You can also send
it
> to a broadcast address for the entire subnet. Its usually async in nature
> (send and forget). EXCELLENT for streaming servers like real-audio (where
> you get clicks for missed packets). it doesn't traverse filewalls well
tho.
>
> I did an remote telemetry thing at uni, between an SGI (nice :) ) and a
PC.
> It had a TCP control 'socket' (give me this, stop, start etc), and UDP for
> the telemetry data - if I missed a packet, the world was not over.
>
> ObAside, the SGI had a 100meg network card in it, and I used it from home.
> It flooded my modem, so I couldn't kill it, and the pipe from Tamaki to
> AKUni was so "small" (2meg) that I bought that down too. good job it was
> about 2am :) I couldn't do that with TCP,only UDP.
>
> >     3. Maintain a connection and know when disconnected.
>
> TCP. Period.
>
> > Nic, your a bit of a wizz at this sort of stuff as I recall,
>
> Not really - my flatmate, Damon, is/was rather a god at it - he wrote a
nice
> sockets library, head and shoulders above the likes of DWinsock. I know a
> lot of the theory, not a lot of the practice.
>
> N
>
> --------------------------------------------------------------------------
-
>     New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
>                   Website: http://www.delphi.org.nz

---------------------------------------------------------------------------
    New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
                  Website: http://www.delphi.org.nz


---------------------------------------------------------------------------
    New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
                  Website: http://www.delphi.org.nz

Reply via email to