| Forum Index > General Forum |
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. | ||
|
bangsholt
Denmark138 Posts
On August 30 2014 18:22 Blisse wrote: I know what sockets are. Am I just asking if I can host my own server at home? I think I'm basically asking that. Yes? What do you intend to it for, then maybe you can get some useful answers. | ||
|
green.at
Austria1459 Posts
On August 30 2014 18:22 Blisse wrote: I know what sockets are. Am I just asking if I can host my own server at home? I think I'm basically asking that. you can if you have a public ip, else you could try no-ip.org , duckdns.org or similar services. | ||
|
wozzot
United States1227 Posts
| ||
|
obesechicken13
United States10467 Posts
On August 30 2014 18:22 Blisse wrote: I know what sockets are. Am I just asking if I can host my own server at home? I think I'm basically asking that. Who doesn't? + Show Spoiler + You put them on your feet right? | ||
|
aksfjh
United States4853 Posts
On August 30 2014 18:22 Blisse wrote: I know what sockets are. Am I just asking if I can host my own server at home? I think I'm basically asking that. Yes. You can turn practically any device into a "host". To talk to it, you need to make sure you have the routing set up. Like somebody said earlier, that might take a service to give you a DNS if you're doing it over the public web, as well as a port forward or something similar on your router (assuming you have the traditional home network set up). If you're doing it internally, all you have to do is point the client device in the direction of the host via network IP. On August 30 2014 23:26 obesechicken13 wrote: Who doesn't? + Show Spoiler + You put them on your feet right? + Show Spoiler [Not quite...] + Only if you're a girl. Socks are for boys, sockets are for girls. ![[image loading]](http://media.her.ie/wp-content/uploads/cdn/default/0001/31/33be0b2f950a2f4b73d1aadc7272e8ea23fad41b.jpeg) | ||
|
nunez
Norway4003 Posts
luckily it's in (and is made in) my workbench directory, where i only have a main.cpp and maybe some temporary headers. i could have sweared i used .o, but prolly got lost inbetween changes. nice spot. @cyx hopefully i will have been able to put together a revamped read by that time with nnary-demux and all. | ||
|
Blisse
Canada3710 Posts
On August 30 2014 23:37 aksfjh wrote: Yes. You can turn practically any device into a "host". To talk to it, you need to make sure you have the routing set up. Like somebody said earlier, that might take a service to give you a DNS if you're doing it over the public web, as well as a port forward or something similar on your router (assuming you have the traditional home network set up). If you're doing it internally, all you have to do is point the client device in the direction of the host via network IP. How secure would that be from any malicious people? Like if someone finds my IP and try to kill my machine. I want to see how viable it is to host a single client as a client-server and have devices as views connecting to the client-server, rather than devices as full clients connecting to cloud server. | ||
|
aksfjh
United States4853 Posts
On August 31 2014 08:24 Blisse wrote: How secure would that be from any malicious people? Like if someone finds my IP and try to kill my machine. I want to see how viable it is to host a single client as a client-server and have devices as views connecting to the client-server, rather than devices as full clients connecting to cloud server. As secure as you end up making it... It's a system/network administration thing. If you want to dive into all that stuff, it's going to take awhile to learn, and your initial setups likely won't be very stable/secure. There's a reason people make a business out of hosting servers and cloud based solutions... | ||
|
Blisse
Canada3710 Posts
I'm not super smart, but I think the naive solution is to create/buy a specific client-server (per user) that processes the information and then just route the user's view logic to each device. But I want to know if there's any technology that does something similar, because launching a new client-server per user seems like a product design decision rather than something that I can create as a service consumer. Does that make sense? If I were creating the product I could say, each user gets a client-server that manages state for the user and I have to manage the costs of that, but if all I can do is consume APIs then my problem is a bit different. I'm thinking about how this would work as a design project for school because this solves the client synchronization problem, and I think it can be enabled with how prevalent "cloud" is becoming. Thoughts? | ||
|
disco
Netherlands1667 Posts
| ||
|
Nesserev
Belgium2760 Posts
| ||
|
Blisse
Canada3710 Posts
For example, suppose I'm making a Twitter app. I can make a Twitter app on each client device (platform). Then I consume Twitter's API from each client. The problem is now I have X number of clients that all consume data, that all have their own models, controllers and views. What I'm describing is, instead of having X number of clients that all consume data, I have one client (controller, model) that consumes the data, and X number of devices (views) that display the data. Is there a way for a consumer of data (via APIs) to create this "client-server" structure that manages the app state? I want to make this structure. Does this exist already? Why does every client consume the API? Why doesn't one structure (me!) consume the API and redistribute it. | ||
|
ZenithM
France15952 Posts
Edit: I mean, in the end, clients have to consume data, whether it's your own or some third-party's is a matter of choice, that's all. | ||
|
WolfintheSheep
Canada14127 Posts
On August 31 2014 12:04 Blisse wrote: Yeah it's hard to explain without a diagram. I tried with a friend and he didn't get it over chat either. For example, suppose I'm making a Twitter app. I can make a Twitter app on each client device (platform). Then I consume Twitter's API from each client. The problem is now I have X number of clients that all consume data, that all have their own models, controllers and views. What I'm describing is, instead of having X number of clients that all consume data, I have one client (controller, model) that consumes the data, and X number of devices (views) that display the data. Is there a way for a consumer of data (via APIs) to create this "client-server" structure that manages the app state? I want to make this structure. Does this exist already? Why does every client consume the API? Why doesn't one structure (me!) consume the API and redistribute it. I'm...not exactly sure what the problem here is... If you want the client-side app to only require a connection to Twitter, then of course all the logic will have to handled in the client app. If you want a 3rd party server to handle all the logic, then...have the clients connect to your server. Of course, what you actually need for you app is naturally dependent on what you expect the client requests to encompass. If you server size is limited, and the data that all the clients collectively would want encompasses the entirety of Twitter, then you shouldn't run the whole shebang server-side. | ||
|
Blisse
Canada3710 Posts
On August 31 2014 12:23 WolfintheSheep wrote: I'm...not exactly sure what the problem here is... If you want the client-side app to only require a connection to Twitter, then of course all the logic will have to handled in the client app. If you want a 3rd party server to handle all the logic, then...have the clients connect to your server. Of course, what you actually need for you app is naturally dependent on what you expect the client requests to encompass. If you server size is limited, and the data that all the clients collectively would want encompasses the entirety of Twitter, then you shouldn't run the whole shebang server-side. I said that's the solution already. I'm asking if that the only solution or if there's any other way of approaching it that I'm not aware of because I don't understand what other technologies exist in the world. I want to know why people don't build their apps like this in the first place or is it already on people's plates. I don't understand why we create a complete MVC solution for each device/platform to consume an API, rather than a single ModelController to consume the API and treat each device/platform as a V. (the way I'm explaining is kinda changing now) Does something exist that already does this or do we just not do it? On the other hand, this is a really cool lesson in how to explain my ideas. I'm not super smart, but I think the naive solution is to create/buy a specific client-server (per user) that processes the information and then just route the user's view logic to each device. But I want to know if there's any technology that does something similar, because launching a new client-server per user seems like a product design decision rather than something that I can create as a service consumer. | ||
|
WolfintheSheep
Canada14127 Posts
Depending on what your program is doing, hosting everything on your server means: A) You are constantly indexing and organizing data from a 3rd party source, or B) Receiving requests and sending calls to that 3rd party by potential thousands every minute. So you either need a massive server infrastructure, or you need a large-but-manageable server with increased calls across a network. By comparison, removing your server system entirely and having everything client-side (plus one call to the 3rd party API), you have a system that scales almost infinitely without the cost of running the servers yourself, with the minimal amount of network latency from the user's end. Of course, if your software requires processes that will make a user's system chug, or you have a very good reason to keep a massive indexed database, then that shifts the weight back over to a cloud solution. But for a lot of systems, having everything on the cloud actually makes things less efficient. | ||
|
Blisse
Canada3710 Posts
On August 31 2014 13:26 WolfintheSheep wrote: Depending on what your program is doing, hosting everything on your server means: A) You are constantly indexing and organizing data from a 3rd party source, or B) Receiving requests and sending calls to that 3rd party by potential thousands every minute. So you either need a massive server infrastructure, or you need a large-but-manageable server with increased calls across a network. About this piece actually, if we do what I've proposed, aren't neither of these in play? My solution acts as though there's one client-server per "user", as in logged in user. All devices access this client-server, so really there's even fewer connections to the actual server than with multiple clients. Item A doesn't seem to apply, and I've reduced Item B? | ||
|
WolfintheSheep
Canada14127 Posts
And Cloud solutions are definitely taking off, but fast and stable internet isn't ubiquitous, even in 1st World Countries. It's much more viable for businesses than ordinary consumers, for the time being. On August 31 2014 13:44 Blisse wrote: About this piece actually, if we do what I've proposed, aren't neither of these in play? My solution acts as though there's one client-server per "user", as in logged in user. All devices access this client-server, so really there's even fewer connections to the actual server than with multiple clients. Item A doesn't seem to apply, and I've reduced Item B? The main problem is that you'll still have some form of overhead. There are all kinds of tricks you could potentially use to minimize it, depending on what exactly you're trying to do, but as long as the user has to connect to your system and your system has to connect to the third party API (Twitter in your example), you're still increasing the network latency. You also have to remember that most users won't tell the difference between software that takes up 1mb or 20mb or hardware space, and that most machines (even handhelds) run fast enough that it's okay for each client machine to do the "heavy lifting". Of course, end of the day a user probably won't tell the difference between either solution...the loss in efficiency is probably negligible from their point-of-view. So the only real concerns are if it's worth the cost of running your own server, and more importantly if you can guarantee 100% up-time. | ||
|
Blisse
Canada3710 Posts
| ||
|
WolfintheSheep
Canada14127 Posts
On August 31 2014 14:47 Blisse wrote: So the benefit to the user is that all my apps are always in sync. If I pull down 10 new tweets on my phone, I don't have to pull down 10 new tweets on my desktop and 10 new tweets on my tablet, because there's just one state. It's been pulled down once, no need to re-query on each device. Well, sort of  .All your devices will have to re-query in some fashion. Either a manual request to your server or some kind of polling. Sort of like how an email client would work, I guess. You can have multiple devices with the same email account, and each device will need some way to check for new mail. The question for you app would be...is it more important for each device to have the same display, or for the device your currently using to have the most up-to-date tweets? | ||
| ||
|
|
WardiTV Invitational
ByuN vs Percival
Cure vs Classic
Shopify Rebellion Sundays
Spirit vs Mixu
Clem vs TBD
RSL Revival
Serral vs Rogue
BlizzCon
IdrA vs MC
Replay Cast
Afreeca Starleague
Light vs JyJ
Soulkey vs hero
WardiTV Weekly
Monday Night Weeklies
Afreeca Starleague
Snow vs Shinee
Shine vs EffOrt
GSL
[ Show More ] |
|
|
EPT
