Connection with database: appserver or session

Feb 26, 2012 at 2:22 PM

Suppose I have a list of IP addresses in a table in a sql table and want to use those addresses for a connection filter (to determine who can connect and who not), where should I place the connection and database logics: appserver of session? Is there any info on this?

Thanks in advance!

Feb 26, 2012 at 2:24 PM

No, in your connection filer.

There is a sample of connection filter in QuickStart!

Feb 26, 2012 at 2:40 PM

Ok thanks, I'll have a go with that. One other question or advise: suppose I want to store/retrieve data in a database, this should be done in the session part but for connection pooling should i place this in the appserver part? 

Feb 26, 2012 at 2:48 PM

If you have a connection pool, you 'd better place it in appServer, because it is shared within global application.

Where to place the code saving/retrieving data from database depends on your business, if the logic is only about a command, the code should be placed in the command. But the logic is a business of the session, then you should leave the code in session definition code.

BTW, if you are using ADO.NET or Entity Framework, you needn't care about connection pool. In this case the pool is already provided by .NET framework.

Sep 11, 2012 at 4:50 PM

Hello, i´m starting with this so sorry if this question is so simple

implementing this library means that i derive/extend AppServer with a TelnetSession and a RequestFilter with DefaultRequestFilterFactory, and create Custom commands extending CommandBase class.

So when i start the AppServer cals Setup(9 and OnStartup and waits to a client conexion. When i connect to client conexion a TelnetSession is started (calls all Session methods) and then using the RequestFilter method attached every "packet" is derived to the corresponfing command class or is handled by the HandleUnknownRequest method at TelnetSession class.


So if this is correct:


what happens if i use EF, and for example call a Web service inside the comand and another client command arrives?( from the same client of course), its created a new instance of command to process? , this is not the place to process long process compared to client packed sent ratio?


where i should manage a list of client connected to the sever? define the vars inside the AppServer, and access from session? or from the command? this is thread secure?


if i would like to manage from outside the status of conexions, resources and so on, it is better to implement special commands and connect with a especial client?

what happends if the protocol is so different from the one used by the clients? should i create another Appserver and communicate both?



Sep 12, 2012 at 2:47 AM

SuperSocket engine only start to receive data from client after a command return. It means if a command takes longer time, the session cannot handler the later request. But you can fix it by always using async api (async of api of data access or remote webservice access) or push you long time consuming task into thread pool. Then you can handling multiple request from one session at the same time.

There is already have api about session manage in AppServer:

Although doc of 1.5 has not been finished, but doc of 1.4 also works in some aspects.

There are many options for different protocol:

1) Merge different protocols to one. The request filter is very useful in this case, if your protocols are similar and the request info classes are same, you can merge them as one protocol. You also can define different request filters for them, but you should define a switch strategy. The property "NextRequestFilter" of request filter is very useful for switching.

2) Different request filters, request info, and different appservers. It requires you configure multiple server instances in config file.

Sep 12, 2012 at 7:53 AM


sorry i would like to clarify where the threading or async starts.

taking a standard configuration of servers with one standard configuration AppServer using TCP with a Session class that uses a start and end character handler for example. what you say is that:


once the server is started on instance of the server is started (from now no multithreading no async) for every client connected one thread is created for the session process (so now multithreading) but you have a pool of threads that can be "garbaged" due to the maxWorkingThreads and minWorkingThreads interval (i don't know if you have more clients than threads if the session.close() is called or the OnSessionClosed on session class is called when a thread is disposed).


when a client send a command (line with start and end chars) the session use the DefaultRequestFilterfactory to ProcessMatchedRequest and send the BinaryRequestInfo to the proper command and the command is processed, if during this process the client sends another command the session can not handle because here the re are not multihreading or async.

if this right i have, as you point, create and manage a thread pooling or async calls inside the command.





Sep 12, 2012 at 8:32 AM

" for every client connected one thread is created"

It's wrong, all listen and receiving are asynchronous, so we need create one thread for each session. Threads are not coupled with sessions.

SuperSocket is event base, if there is something received/connected, there will be threads started but most of them come from thread pool (working thread pool, IOCP thread pool).