• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 437
  • Last Modified:

I/O Completion Ports

I have been designing a windows ftp server with IOCPs model,but encountering some problems.
1.How to detect the time out(if some clients connected to the ftp server ,and never post any authorization data,the worker thread will not be notified).My current solution is to spawn an extra thread to check the time out of all connected clients,but it's not a good solution.
2.Is it possible to do the file transfer operation(download or upload) without spawning new threads for those clients requesting the "retr" or "stor" command.If it's possible,how would it be?
3.Is any good source code related to IOCPs rather than the echo server source code(the echo server source code is just too simple and  not taking the time out problem into account)

0
WinEggdDrop
Asked:
WinEggdDrop
1 Solution
 
AlexFMCommented:
1. If you are working with thread pool, the only way to detect idle client is to test all clients using special thread, as you do. I guess you have some class or structure associated with client, keep last client activity time there.
If you have worker thread for each client, setting timeout for wait operation (for example, GetQueuedCompletionStatus) detects idle client.

3. I learned a lot about IOCP from this sample:

http://www.codeproject.com/internet/winsockiocp.asp

It contains some minor bugs (like memory leaks), I spent some time to correct them. But it is good program to get general idea of IOCP programming.
0
 
grg99Commented:
What's wrong with a helper thread?  You may want one anyway in order to update any current status display.

0
 
WinEggdDropAuthor Commented:
http://www.codeproject.com/internet/winsockiocp.asp

It's buggy and it doesn't work at all(I doesn't modify any code),but the idea is good.
0
Cloud Class® Course: Microsoft Exchange Server

The MCTS: Microsoft Exchange Server 2010 certification validates your skills in supporting the maintenance and administration of the Exchange servers in an enterprise environment. Learn everything you need to know with this course.

 
WinEggdDropAuthor Commented:
To grg99:
Nothing wrong with a helper thread,but assume I use singly linked list to store every request information,so every time I detect the time out, I have to go through the whole linked list(this list is shared data,I have to take a great care with some sort of critical session).If the linked list grows large,it just takes time,and as doing so,the new incoming connections will be blocked since the thread handling the incoming connections is unable to access the share data when detecting time out is in progress.
0
 
WinEggdDropAuthor Commented:
To AlexFM:
     MSDN sdk's IOCP sample is better than that code,you can take a close look.
0
 
grg99Commented:
>To grg99:
>Nothing wrong with a helper thread,but assume I use singly linked list to store every >request information,so every time I detect the time out, I have to go through the >whole linked list(this list is shared data,I have to take a great care with some sort of >critical session).If the linked list grows large,it just takes time,and as doing so,the >new incoming connections will be blocked since the thread handling the incoming >connections is unable to access the share data when detecting time out is in progress.

It should jsut take nanoseconds to compare a timeout value in each node, so I wouldnt worry about taking too much time with this.

It would be even easier if you'd organize the list with the oldest ones at the end, and reverse pointers so you can just peek at the end node and time it out as needed.  No searching required.

0
 
mturk1Commented:
I'm not aware of your current design but the IOCP might not be the best solution since
you are building FTP server that is a state protocol.
The easiest solution is to have as many worker threads as the maximum allowed number of
connected users is, so in such cases you won't need the IOCP's at all but rather a thread
pool that you may pull off for each new connection.
The IOCP can be useful for a situations that you wish to create a huge amount of
allowed connected users, but that implies that you only have limited set of active transactions
going on. This mean that only 100 hundred users from for example 500 allowed can be served in
any point in time. So if happens that all 100 users are downloading a file then the rest 400 hundred
will be blocked out. This is not a very good design for FTP server thought.
So instead having IOCP that is meant to be used in stateless protocols like HTTP use the thread
pool instead with the configured number of maximum allowed connections.
You may further more make that thread pool dynamic from min to max to deal with not so frequent
connection bursts.

So in any case if you stick with the IOCP idea you will still need the array that will hold the
client info and it's size will be the size of a maximum allowed connected users.

In both cases you'll need to acquire the worker thread after the client connects, and then
use the read timeout using setsockopt. This value will give you the needed timeout.
There is no need to use the separate thread to monitor the timeout. It can be inherently obtained
using socket read timeouts

MT.
0
 
WinEggdDropAuthor Commented:
To mturk1:
all You suggested are the multi-thread + blocking socket model,and I have already implemented a ftpd in that model,and it's pretty easy to accomplish,but what that model missing is scalable.IOCP isn't like you said above.I did a test on ftpd of each model,IOCP used less system resource,especially as the login users are huge(ect,1000 con-current connection)
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now