Hi all,

I am learning about socket programming from the books from Richard
Stevens. I just started, but browsing thru the books I didn't find an
example of how one could implement a program that uses two sockets for
communication (like for example the FTP command, which uses a data and
a command socket).

I am trying to write such a program myself, but I can't really get
around the design of the program. My questions is relatively simple (I
think). How would I go about setting up communication with two
sockets? I just need ideas on how to do this. I've been trying to get
this working for a long time, but I guess my design is wrong.

I can get it to work in a none concurrent program, but I want to allow
multiple clients connecting from the same or different machines. The
program has to be some kind of FTP alike, but a lot simpler. The
clients asks for a list of files and the server returns this. The
clients asks for a specific file and the server returns this files in
blocks of 1024 bytes (The file is send over another port than the file
names).

It is just for me to learn more about network programming... That's
why I don't need code, but ideas on how to set this up or references
on information that might help me out. (I have the books by Richard
Stevens, so if it is in there that would be nice too)

If this is the wrong mailing-list, please let me know.

Thanks in advance,
Kind regards,
Roel.

[ Post a follow-up to this message ]

rsergeant <rsergeant@gmail.com> writes:
> I am learning about socket programming from the books from Richard
> Stevens. I just started, but browsing thru the books I didn't find an
> example of how one could implement a program that uses two sockets for
> communication (like for example the FTP command, which uses a data and
> a command socket).
>
> I am trying to write such a program myself, but I can't really get
> around the design of the program. My questions is relatively simple (I
> think). How would I go about setting up communication with two
> sockets? I just need ideas on how to do this. I've been trying to get
> this working for a long time, but I guess my design is wrong.

There are basically two options: Use a thread for each socket. Use an
I/O multiplexing routine to distribute I/O-tasks some number of threads
less than the number of sockets. The basic system calls for this would
be 'poll' and 'select'. 'poll' is easier to use and more efficient for
small sets of descriptors, 'select' is not the AT&T designed interface
(important quality :-> ), was a clever hack on VAXen when the running
kernel supported at most 32 open descriptors per process and is
portable to Windows.

> I can get it to work in a none concurrent program, but I want to allow
> multiple clients connecting from the same or different machines. The
> program has to be some kind of FTP alike, but a lot simpler. The
> clients asks for a list of files and the server returns this. The
> clients asks for a specific file and the server returns this files in
> blocks of 1024 bytes (The file is send over another port than the file
> names).

The easiest way to do this is to fork a new process for each newly
accepted connection. This is not the most efficient way to implement
such a server, but completely appropriate for servers servicing
relatively few clients.

[ Post a follow-up to this message ]

On Nov 23, 11:48 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:

> There are basically two options: Use a thread for each socket. Use an
> I/O multiplexing routine to distribute I/O-tasks some number of threads
> less than the number of sockets. The basic system calls for this would
> be 'poll' and 'select'. 'poll' is easier to use and more efficient for
> small sets of descriptors, 'select' is not the AT&T designed interface
> (important quality :-> ), was a clever hack on VAXen when the running
> kernel supported at most 32 open descriptors per process and is
> portable to Windows.

Thanks Rainer,
I used poll in combination with two seperate connection threads. If
now works
as I expect. It took some though before I got it working.  I will try
select next.

> The easiest way to do this is to fork a new process for each newly
> accepted connection. This is not the most efficient way to implement
> such a server, but completely appropriate for servers servicing
> relatively few clients.

Also this way works fine.

[ Post a follow-up to this message ]