Jump to content
  • Advertisement
Sign in to follow this  
Cosmic314

Server output to clients

This topic is 2133 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a server that uses sockets to connect with clients.  These connections are not persistent.  The typical usage pattern is to submit 'work' to the server.  It receives the job, checks as best as it can that it can actually satisfy requirements, notifies the user, and then disconnects the client.  The workload can be queued behind an arbitrary number of tasks, so the time the server starts to perform a specific job is not easily predictable.  When it goes to perform a task it could encounter an error.

 

My question is:  How can I let a user know information about the error it receives?  In my case, jobs typically create their own work area where they produce results on a shared filesystem.  I can, and do, report errors here.  However, a certain class of errors can occur before an appropriate directory structure is created.  If I can't place them into a file under this structure how will I report them?

 

Some of my ideas:

 

1)  Allow the client to retrieve job results through a separate communication with the server.  This will require the server to record the status of failed workloads.  I could start consuming memory pretty quickly if I keep this data around for too long.  I supposed I could store the results in a file in a general location and retrieve on demand.

 

2)  Require that each client have a pre-defined workspace prior to submitting the job.  The server will require that this directory exist and be writable before it will accept jobs.

 

3)  Email every failure.  However, this doesn't appear too attractive to me.  A tool which creates automated dispatches might make the same error on a large number of jobs.  When the user goes to read email -- disaster!

 

Anyways, do any of these solutions seem reasonable?  What other ways might I consider?

 

Thanks!

Share this post


Link to post
Share on other sites
Advertisement

All of those sound reasonable to me.

 

I'd say that preventing the error occurring in the first place by doing more up-front validation is ideal. The sooner you know about a problem, the quicker it is to fix.

 

Instead of always emailing I'd add options for when to email the user. I'm guessing it might be handy in some cases to email them on errors, on job start, and on job completion. You may also want a per-user rate limiting option (e.g. send me no more than one email per hour) so that automated jobs can report errors without spamming the person looking after them.

 

I'd imagine that keeping a log file on the server of the errors might come in handy in cases where email was disabled. This doesn't need to be anything more complicated than a text file, although it's probably worth having a system to switch to a new file when the current one gets too big. That makes it easier to delete old data.

 

As a side note this sounds a lot like what a continuous integration product does, apart from the jobs not being compilation of source code. You might want to check out one for ideas.

Share this post


Link to post
Share on other sites

All of those sound reasonable to me.

 

I'd say that preventing the error occurring in the first place by doing more up-front validation is ideal. The sooner you know about a problem, the quicker it is to fix.

 

Instead of always emailing I'd add options for when to email the user. I'm guessing it might be handy in some cases to email them on errors, on job start, and on job completion. You may also want a per-user rate limiting option (e.g. send me no more than one email per hour) so that automated jobs can report errors without spamming the person looking after them.

 

I'd imagine that keeping a log file on the server of the errors might come in handy in cases where email was disabled. This doesn't need to be anything more complicated than a text file, although it's probably worth having a system to switch to a new file when the current one gets too big. That makes it easier to delete old data.

 

As a side note this sounds a lot like what a continuous integration product does, apart from the jobs not being compilation of source code. You might want to check out one for ideas.

Thanks for the advice.

 

Providing user controlled email options is a good idea.

 

I do already have logging options that keep track of the internal operation of the servers.  I could make a user log too.

 

The operation of my system involves a main server that distributes jobs to other subordinate servers.  These subordinate servers often have hardware directly attached to these machines (USB, SATA, etc.) which they need to use.  Or a different OS is needed to run different client software.  I feel like I'm using a design pattern, except my abstract interfaces are allowed to point to remote code. :P  At other times, nearly any machine can handle a job and so the server will attempt to load balance.

 

It's an interesting project, taking me out of my normal assembly / C duties.  I had originally started writing this whole scheme in C.  I reached a point where it just became too painful to refactor.  I made the move to C++ and now am slowly adding C++11 features as well.  I came onto the C++ scene just at the right time!  (Well, I did program C++ years ago.  It's embarrassing to look at that code.)

 

I'll do some exploring of the contiguous integration products that you mention.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!