Re: Simple byte(s) transfer by the internet
- From: "Skybuck Flying" <nospam@xxxxxxxxxxx>
- Date: Mon, 14 Nov 2005 09:52:00 +0100
Yes on top of Maarten Wiltink's advice I would advice anyone wanting to
learn how to use these properties and tcp/udp internet technology in general
to take a long hard look at winsock and try to learn how it works... because
all these components are based on winsock etc.
If you understand winsock well etc then using these components will be no
problem what so ever.
Otherwise these components might see a little bit abstract and a bit
confusing ;)
At least that's how I experienced it before I knew winsock =D
Ofcourse learning winsock and the socket concept etc... requires some time
etc ;) which you might not have in that case to bad :)
Bye,
Skybuck =D
"Maarten Wiltink" <maarten@xxxxxxxxxxxxxxxxxx> wrote in message
news:4377c17f$0$11074$e4fe514c@xxxxxxxxxxxxxxxxx
> <markbng@xxxxxxxxxxx> wrote in message
> news:1131918052.956288.169340@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > I am looking for a way to communicate between two applications by the
> > internet. One application (client) just send a request (few bytes) to
> > the other application (server) and the first application gets an answer
> > back (also a few bytes). It must be possible to serve more clients and
> > to enable password protection or other limitations (access to certain
> > ip's or mac's).
> > I don't know much about internet communication. What kind of
> > communication can I use (TCPIP or UDP)? What port? What component can
> > I use? Any help is welcome. Thanks in advance.
>
> For the basics, TClientSocket and TServerSocket serve very well.
>
> TCP gives you a reliable connection, which means you can focus on making
> your own logic work without having to worry about losses and timeouts.
> However, it hands you a _byte stream_. Any framing you require, you must
> supply yourself. Send buffers may be delayed for up to two seconds and
> arrive split and merged (but not reordered) arbitrarily.
>
> Framing is easily handled by sending text, not binary data, and ending
> each line with CRLF. This also allows telnetting to a server by hand, an
> invaluable debugging technique. Also allows debugging a server without
> having to write a client immediately.
>
> Virtually any port can be used to run a server on as long as it's not
> in use. An incomplete list of what is expected where (or where is
> expected what, not quite the same thing) is in the etc/services file,
> which Windows keeps in %systemroot%/system32/drivers. It's a good
> habit to at least try to avoid collisions. Don't assume you're the
> first to start counting at 10,000.
>
> With multiple clients, keep track of where a command came from by
> checking the event parameters. Send replies back to the same connection.
>
> There are several events where connections can be vetted before being
> allowed. IP addresses are everywhere, MAC addresses are much harder
> to find out because they're at a lower level.
>
> Groetjes,
> Maarten Wiltink
>
>
.
- References:
- Simple byte(s) transfer by the internet
- From: markbng
- Re: Simple byte(s) transfer by the internet
- From: Maarten Wiltink
- Simple byte(s) transfer by the internet
- Prev by Date: Re: const list : array of string = ( 'aa', 'bb', 'cc' ); not possible
- Next by Date: Re: ownerdrawing (on a components canvas): comitting any sins here?
- Previous by thread: Re: Simple byte(s) transfer by the internet
- Next by thread: Re: Simple byte(s) transfer by the internet
- Index(es):
Relevant Pages
|
Loading
