none
C# - Join to some network and give one code only once to every user. RRS feed

  • Question

  • Hello, is there any way to make list of codes and when user claims the code the code will get deleted and other users will be able only to claim others codes (not deleted). I have never done anything with network or sql.

    Monday, August 27, 2018 1:39 PM

Answers

  • So that means you're going to be running the app on any # of client machines and they'll all have to talk to the same shared data source so you don't give away the same code multiple times. This sounds like a client server app to me.

    You'll create a REST (or perhaps WCF) service hosted online somewhere. It is important that it is shared by all the clients so you don't give out duplicate codes. For security reasons you'll want to make sure it authenticates with only your client app and is behind SSL.

    On the client side it will call the service to request an available code. I would strongly recommend an accept/acknowledge approach here. The server sends the next code that is available. The client then sends an ack to say it got it. This will handle cases where the network goes down. You don't want to mark codes as used that the client never got. However this also means you should mark the code as potentially in use so other clients won't get it either. Once the client has ack the code it can then give it to the user. 

    On the server side you'll get the next available code from your store. You'll want to mark it as potentially being used so it won't get returned again. Then it returns it to the client. When the client calls back to the server with an ack the server will then mark the code as used.

    Personally I would recommend against deleting the codes from the DB. Instead I would add a column or 2 to the DB that indicates that a code has been used and some additional auditing data. For example you may get an email later from a client saying they got code XYZ and it isn't working. You can use your DB to verify the code was actually sent, when, to who, etc. What you log is up to you. 

    The DB is also where the code can be marked as partially used. For example when the original code is sent to the client you might record the client ID or other unique information with the code on the server. If the client calls your server again you for another code you can return the same code again until they eventually ack it. This would handle network failure issues or duplicate network requests.

    For getting the next available code your service would simply query the DB for the next code that is not already used. For concurrency reasons you'll actually want to probably do an update-select as a single call. This will cause the DB to find the next row and then update it as immediately (partially) used. If 2 calls come in at the same time they'll get different rows. If you're using SQL Server then consider using a ROWVERSION column for helping with concurrency.

    The downside to storing your available codes in the DB is that at some point you'll run out and need to add some more. An alternative may be (assuming Steam supports) to have your service request a new code from Steam on demand. You can still store the data in a DB so you know you got it and the clients wouldn't be impacted either way. The advantage to this approach is that you don't get keys (or charged for them I assume) until you need them and you never have to worry about running out of them. Again, I don't know if Steam allows this, you'd have to look at their documentation.


    Michael Taylor http://www.michaeltaylorp3.net

    Monday, August 27, 2018 4:19 PM
    Moderator

All replies

  • Please clarify what you're asking for. Are you trying to implement something in C#, SQL, part of some network login attempt, etc?

    Michael Taylor http://www.michaeltaylorp3.net

    Monday, August 27, 2018 2:01 PM
    Moderator
  • Please clarify what you're asking for. Are you trying to implement something in C#, SQL, part of some network login attempt, etc?

    Michael Taylor http://www.michaeltaylorp3.net

    I say i dont know how to do it! I want to find a way how to make a list of codes and when user recieves a code no more users can recieve this code...
    Monday, August 27, 2018 2:07 PM
  • What codes are you talking about? Are you talking about some sort of one time access code? If so then what type of application is it? How are the codes generated (if at all yet)? How long do they need to be good for? How secure do they need to be (e.g. authentication, promo code, etc)? 

    Michael Taylor http://www.michaeltaylorp3.net

    Monday, August 27, 2018 2:55 PM
    Moderator
  • What codes are you talking about? Are you talking about some sort of one time access code? If so then what type of application is it? How are the codes generated (if at all yet)? How long do they need to be good for? How secure do they need to be (e.g. authentication, promo code, etc)? 

    Michael Taylor http://www.michaeltaylorp3.net

    The Game code. Steam Game code as reward for using my app. I dont know about security. I just want some storage. Ill give codes to that storage  and the c# wfa application will take the code and give it to user. Every code have to be give awayed only once! The key looks like XXXXX-XXXXX-XXXXX, the code works until activated


    Monday, August 27, 2018 3:18 PM
  • So that means you're going to be running the app on any # of client machines and they'll all have to talk to the same shared data source so you don't give away the same code multiple times. This sounds like a client server app to me.

    You'll create a REST (or perhaps WCF) service hosted online somewhere. It is important that it is shared by all the clients so you don't give out duplicate codes. For security reasons you'll want to make sure it authenticates with only your client app and is behind SSL.

    On the client side it will call the service to request an available code. I would strongly recommend an accept/acknowledge approach here. The server sends the next code that is available. The client then sends an ack to say it got it. This will handle cases where the network goes down. You don't want to mark codes as used that the client never got. However this also means you should mark the code as potentially in use so other clients won't get it either. Once the client has ack the code it can then give it to the user. 

    On the server side you'll get the next available code from your store. You'll want to mark it as potentially being used so it won't get returned again. Then it returns it to the client. When the client calls back to the server with an ack the server will then mark the code as used.

    Personally I would recommend against deleting the codes from the DB. Instead I would add a column or 2 to the DB that indicates that a code has been used and some additional auditing data. For example you may get an email later from a client saying they got code XYZ and it isn't working. You can use your DB to verify the code was actually sent, when, to who, etc. What you log is up to you. 

    The DB is also where the code can be marked as partially used. For example when the original code is sent to the client you might record the client ID or other unique information with the code on the server. If the client calls your server again you for another code you can return the same code again until they eventually ack it. This would handle network failure issues or duplicate network requests.

    For getting the next available code your service would simply query the DB for the next code that is not already used. For concurrency reasons you'll actually want to probably do an update-select as a single call. This will cause the DB to find the next row and then update it as immediately (partially) used. If 2 calls come in at the same time they'll get different rows. If you're using SQL Server then consider using a ROWVERSION column for helping with concurrency.

    The downside to storing your available codes in the DB is that at some point you'll run out and need to add some more. An alternative may be (assuming Steam supports) to have your service request a new code from Steam on demand. You can still store the data in a DB so you know you got it and the clients wouldn't be impacted either way. The advantage to this approach is that you don't get keys (or charged for them I assume) until you need them and you never have to worry about running out of them. Again, I don't know if Steam allows this, you'd have to look at their documentation.


    Michael Taylor http://www.michaeltaylorp3.net

    Monday, August 27, 2018 4:19 PM
    Moderator
  • So that means you're going to be running the app on any # of client machines and they'll all have to talk to the same shared data source so you don't give away the same code multiple times. This sounds like a client server app to me.

    You'll create a REST (or perhaps WCF) service hosted online somewhere. It is important that it is shared by all the clients so you don't give out duplicate codes. For security reasons you'll want to make sure it authenticates with only your client app and is behind SSL.

    On the client side it will call the service to request an available code. I would strongly recommend an accept/acknowledge approach here. The server sends the next code that is available. The client then sends an ack to say it got it. This will handle cases where the network goes down. You don't want to mark codes as used that the client never got. However this also means you should mark the code as potentially in use so other clients won't get it either. Once the client has ack the code it can then give it to the user. 

    On the server side you'll get the next available code from your store. You'll want to mark it as potentially being used so it won't get returned again. Then it returns it to the client. When the client calls back to the server with an ack the server will then mark the code as used.

    Personally I would recommend against deleting the codes from the DB. Instead I would add a column or 2 to the DB that indicates that a code has been used and some additional auditing data. For example you may get an email later from a client saying they got code XYZ and it isn't working. You can use your DB to verify the code was actually sent, when, to who, etc. What you log is up to you. 

    The DB is also where the code can be marked as partially used. For example when the original code is sent to the client you might record the client ID or other unique information with the code on the server. If the client calls your server again you for another code you can return the same code again until they eventually ack it. This would handle network failure issues or duplicate network requests.

    For getting the next available code your service would simply query the DB for the next code that is not already used. For concurrency reasons you'll actually want to probably do an update-select as a single call. This will cause the DB to find the next row and then update it as immediately (partially) used. If 2 calls come in at the same time they'll get different rows. If you're using SQL Server then consider using a ROWVERSION column for helping with concurrency.

    The downside to storing your available codes in the DB is that at some point you'll run out and need to add some more. An alternative may be (assuming Steam supports) to have your service request a new code from Steam on demand. You can still store the data in a DB so you know you got it and the clients wouldn't be impacted either way. The advantage to this approach is that you don't get keys (or charged for them I assume) until you need them and you never have to worry about running out of them. Again, I don't know if Steam allows this, you'd have to look at their documentation.


    Michael Taylor http://www.michaeltaylorp3.net

    I have never used one of those. REST, WCF, Sql.
    Anyway i have one free sql DB, but i dont know how to connect to it or how to write into it.

    I found this Microsoft libary for rest https://msdn.microsoft.com/en-us/library/jj819168.aspx
    But where can i make one DataBase? Are the tutorials on internet good?

    Or could be fine just using the SQL?

    Tuesday, August 28, 2018 8:12 AM
  • Unfortunately a forum post isn't going to be able to answer all this for you. You can find everything online with examples. I'm providing links in the text below to some starter material.

    As for creating a database you'll want to use look at the documentation for whatever database you intend to use. For SQL, as an example, you can find help here. Getting help related to SQL can be done in the SQL Forums. As for what data to store, columns to create, etc that is going to depend upon your table structure. The SQL folks can help you with that if needed.

    For talking to the database in C# you'll need to decide what data access layer you'll use. Most people in .NET tend to use Entity Framework. You can get help for it in the EF forums. 

    Writing a REST (or WCF) API is an entirely different ballgame. You need some web experience for that. You can get full support over in the ASP.NET forums.

    Personally, if you're new to all this then I think you need to break your problem down into a simpler one. Trying to take this all on at once without experience is going to be overwhelming. I'd start by building your client without generating any codes. Once that is working then move on to writing a REST API that talks to a DB and get distribute codes. Then add the connection between your client and server.

    For any of this to be useful you're going to have to host your REST service somewhere everyone has access to so you're going to have to start thinking about hosting concerns as well. That costs money. All this assumes you cannot call Steam on demand and get the codes as mentioned previously. If you could do that then you don't need the REST or even database stuff.


    Michael Taylor http://www.michaeltaylorp3.net

    Tuesday, August 28, 2018 1:51 PM
    Moderator
  • Unfortunately a forum post isn't going to be able to answer all this for you. You can find everything online with examples. I'm providing links in the text below to some starter material.

    As for creating a database you'll want to use look at the documentation for whatever database you intend to use. For SQL, as an example, you can find help here. Getting help related to SQL can be done in the SQL Forums. As for what data to store, columns to create, etc that is going to depend upon your table structure. The SQL folks can help you with that if needed.

    For talking to the database in C# you'll need to decide what data access layer you'll use. Most people in .NET tend to use Entity Framework. You can get help for it in the EF forums. 

    Writing a REST (or WCF) API is an entirely different ballgame. You need some web experience for that. You can get full support over in the ASP.NET forums.

    Personally, if you're new to all this then I think you need to break your problem down into a simpler one. Trying to take this all on at once without experience is going to be overwhelming. I'd start by building your client without generating any codes. Once that is working then move on to writing a REST API that talks to a DB and get distribute codes. Then add the connection between your client and server.

    For any of this to be useful you're going to have to host your REST service somewhere everyone has access to so you're going to have to start thinking about hosting concerns as well. That costs money. All this assumes you cannot call Steam on demand and get the codes as mentioned previously. If you could do that then you don't need the REST or even database stuff.


    Michael Taylor http://www.michaeltaylorp3.net

    Thanks, Ill try to do SQl database somehow from tutorials. I am making like little c# projects for 2years but now im making a bigger (first what i release to people) so im trying to do the best.

    The steam codes are purchasable so i can have as much as i want.

    Anyway if I have any problem can I contact you?


    Tuesday, August 28, 2018 4:37 PM
  • The best approach would be to create a new thread in the forums and reference this thread. Then anyone can provide assistance and will have the contextual information to assist you.

    Michael Taylor http://www.michaeltaylorp3.net

    Tuesday, August 28, 2018 5:29 PM
    Moderator