As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm starting my 3rd year in a Computer Science degree , and I need to pick a project and develop within the following year.
I'm searching for unique ideas for a project , I have some ideas , however I still have my doubts about them , whether or not they are good enough to develop and etc .
For example :
Client / Server application for supermarkets (food) with DB queries
Iphone application
Cellular dating system
...
I'm sure that all of you (SO members) at some point of your careers came across (and still are) an interesting project (or projects) , so any idea would be greatly appreciated.
4/ World grave database. Grave position (google maps) of every human (first and last name + birth and death date).
If this becomes some hit, I want % ;-)
A mobile app that lets people friend each other, supports location services, allows you to display a map showing you where all of your friends are and click to send an SMS telling them to stay put because you're on your way.
It really depends on what your interests are, but if it were me I would focus on a project that lets me explore the possibilities of solving a problem via the integration of a broad range of technologies and architectures: a web or iPhone app with a social element that makes use of cloud resources and scaling technologies like Hadoop or Cassandra.
I write networking code as my job. Here are some out-of-hours prototyping projects I've done recently, that might make it into our product in the next year. You want to pick something that's doable and has no external factors, so you can guarantee to get it working solidly.
A WOL service. A central server maintains connections to client nodes, which check in through a service that runs when the machines are awake. They send their MAC on checkin. The channel must be secure, and only registered accounts can authenticate with the central server. Each machine runs a low-frequency broadcast service (UPnP-style) that advertises its presence to other machines on the service's network. When a node thinks it's picked up a signal from another node, it exchanges a challenge with it, and sends the result to the central server. Thus, the central server can validate that the machines are indeed 'adjacent' (able to contact each other directly), and that neither machine is lying about the location of the other.The point of this: if you have the login details for a node, the hosted service will relay a WOL instruction to any other node on the network which was known to be adjacent to the target node when it was last up. You can therefore wake your machine remotely when you don't access to its subnet, assuming at least one other machine on the subnet is turned on and checked into the service.That's an ambitious project, but possible for a motivated student with a good grasp of networking.
Secondly, how about a VPN service? Do STUN on a central server to help two non-adjacent computers connect to each other and establish an SSH-style protocol with flow-controlled channels to perform port-forwarding (keep it simple: a SOCKS proxy on the client end is preferable to trying to do a full point-to-point network bridge with 'true' VPN capabilities).
I've got each of these to a working prototype in just under a day of coding each (using a few pre-written components from earlier), so for a student who's still learning C and network programming, they might be suitable year projects. I don't what level your university would push you to though.
Related
I have come across a term SDN (software defined network). I have gone through some related webpages and understood that it is basically related to networking virtualisation. I want to understand SDN from an application developer/programmer's perspective. For example, if I have created a set of websites and web services (in .Net), what are the things that would be different in SDN than in a conventional network, in terms of development and deployment.
I would appreciate if somebody could explain this with an example.
Thanks a lot.
Before I say anything I should mention everything I say here might be changed in future. The reason is that this field is still in the research area and might face some modifications in future. Even some use cases may be removed or added.
One thing I should maybe add is that SDN is not just network visualization. It could be more than that. I think it is better to say one of the applications/usages of SDN is network visualization.
Let's consider onos:
ONOS is implementing an controller which internet service providers would use to cerate path and links. ISP's just specify the two end points and then ONOS goes and sends flows to different switches in order to make path between them. ONOS calls it "intent", that is an intent is created between two points.
Imagine Datacenter (DC) A wants to backup it's data at 3 am tomorrow. With SDN they can call their ISP and ask for a "path" at 3am tomorrow with bandwidth of 50Gb/s. The two DC may have full view of the network or just a subset of the view. (i.e. visualized view ) The ISP's SDN controller would go and program the required switches using OF commands to create that path for the two DC.
SDN is mostly used in programming network. For example:
As you said network visualization
Network Access Control -> kinda Security
Datacenter Optimization
Dynamic Interconnects -> creating paths and stuff
Another possible usage is the following: Let's say you have your website up and user/client want to connect to your website and browse it. One can say, users need to create a path from client to your server using their ISP. However, I think this maybe by the browser for you. I doubt this is feasible but I've heard this usage too.
In general I think SDN would not make a big change in terms of web browsing and web servers. Usually web browsing is just short connections and packets. I think SDN would make more sense for long time connections like backing up a whole DC or streaming videos. The reason is that configuring a path from client to host is a bit expensive and a bit time consuming (at least with the current technology) so it is worth it for connections over a long period.
I hope it helps.
Well, I tried to ask this question as a comment on this question, but I thought that maybe no one will notice it, so I decided to ask it as a separate one.
The question is about how to do real-time GPS tracking system things; if we have the following scenario:
Rather than connecting a GPS receiver to a PC, the user will have a mobile device with an integrated GPS receiver.
Location data will be sent over mobile network using GPRS data connection to a server side.
The data will be processed and a KML path file will be created and updated on time intervals and used to track the user using Google Earth.
The question is: what is the best method to accomplish this scenario for the server side; is it a web service, a web application, a windows service, a windows application or what exactly? Taking into account that the system will serve a number of users simultaneously, and that more users may use the system in the future(scalability issues).
Thank you in advance and I highly appreciate any help :)
What kind of device are you using exactly, something like this or something more sophisticated / configurable? If we assume that the device sends its data over TCP, I would consider the following approach with separate input/output processes:
Input: a process listening specific TCP port and storing incoming coordinates to database with a device id. Preferably, your listening loop must be able to handle simultaneous connections without them blocking each other.
Output: web application reading coordinates from database for a given device id and displaying them through the Google Earth API.
Use whatever programming language(s) you are familiar with.
For me there is a technical limitation/risk here -> the mobile device, and its connectivity.
1) What are your requirements? Do you need to support various mobile devices or will you focus on only one platform ?
2) More importantly, you have to understand that GPRS data connections differ from a PC connected to the Internet. There are various connection restrictions imposed by different mobile operators.
If I was to design such a system in order to minimise those risks I would go with a web server running on port 80 which the mobile devices would upload their Long/Lat through POST (or even GET to simplify things).
EDIT: Regarding scalability, it would be very easy to scale things up in the future using tried&tested load-balancing techniques.
EDIT2: Whichever technology you decide to use, i would HIGHLY recommend that the first thing you do is to mock up a prototype. Those connection restrictions could be show-stoppers. Ideally you need to explore them before you have made any serious investment.
How can I build a simple 2-player game, that communicates over the internet?
I need to solve the problems of:
lookup or rendezvous - two players want to find each other.
ongoing communications. Either player can initiate an action that requires delivering information to the other side, in a reasonbly quick timeframe (IM-type latency, not email-type latency).
In this regard, I suppose it is equivalent to a 2-way chat, where people want to be able to find each other, and then also, once paired up, intercommunicate.
Further requirements:
for now, assume the endpoints are Windows OS, relatively recent.
assume neither endpoint machine is directly accessible from the internet. Assume they are client machines, hidden behind firewalls that block incoming requests. The machines can make outbound requests. (say, over HTTP, but TCP is also fine)
communication should be private. For simplicity, let's say there's a shared secret already in place, and the endpoints are able to do AES. I guess what I mean by this is, any intermediary should not need to decrypt the message packets. The decryption will happen only at the endpoints.
all custom code should run only on the client PCs.
Assume there is no server in the internet that is under my control.
I'm happy to use third-party servers to facilitate intercommunication, like an IM server or something, as long as it's free, and I am not required to install custom code on it.
What APIs are available to facilitate this design?
Can I do this with IM APIs? WCF? Are there WCF Channels for Windows Messenger?
What protocols? HTTP? I have this tagged as "peer-to-peer" but I mean that virtually; there's no hard requirement for a formal p2p protocol.
What message formats would you use?
EDIT
To clarify the requirements around servers, what I want is NO SERVER UNDER MY CONTROL. And NONE OF MY CUSTOM CODE ON ANY SERVER. That is not the same as "No server".
Think of it this way: I can send an email over SMTP, using custom code that I write on the sending and receiving side. My custom code can connect via a free SMTP server intermediary. This would require no installation of code on the SMTP server. This is something like what I want, but SMTP is not acceptable, because of the latency.
EDIT2
I also found this: library for Instant Messaging, like libpurple, but written in C#
ANSWER
I can do what I want, using libraries for IM frameworks. One simple way to do it using Windows Live Messenger is to use the Messenger Activity SDK. This proves the concept, but is not really a general solution. But, similar things can be accomplished with the IM libraries for various messenger systems, like libpurple, or using libs for IRC channels. In all these cases, the IM servers act as the firewall-penetrating communications infrastructure.
IM is the wrong tool. Instead, use an IRC chat room.
With an IRC chat room, your clients "log in" to the chat room, and that is used for your "presence". Anyone in the chat room is "available" to play the game.
Once that is done, the game instance communicate with each other through the chat room. They can use the global channel, or simply private IRC channels for game traffic.
The issues to solve:
First, all game state is shared on the clients. Many games have done this (RTS's like Age of Empires, RPGs like Diablo). But client states are susceptible to hacking and cheating. That's just a plain truth. If the game is popular, it WILL be hacked.
Ping traffic. Basically the flow is you log in to the room, your client is in "available to play" mode. Then it pings EVERYONE ELSE to see if THEY are available to play. This will happen with every client "sign in" to the chat room. You can then use the public room for broadcast events "Frank is ready for a new game", "Frank started a game with Joe", etc. That can help keeps games in sync and not chatty, but when a client connects to the chat room, it's going to go "Hi All, it's Bob, what are you all doing". So you need to manage that.
Traffic volume. IRC rooms can handle a lot of traffic, but not a LOT of traffic. Most are designed to prevent "spamming", "flooding", etc. So you may well be rate limited on you game play. Not a problem for "Checkers", more so for "World of Warcraft" during a 40 man Raid. That's a game design issue.
Terms of service. The IRC provider may well say "Uh no, you can't do that with our service". I haven't looked in to it, so I don't know, but could be an issue.
Other than that, IRC is a pretty good fit. Lots of IRC bot code floating around on the net, I've never used any of it.
Every two-player game must have some type of server environment by the basic need of having to communicate between two clients/players at the very least. Keep in mind, each of the clients/players can also act as its own server to communicate with other linked clients. But the need to keep tabs on all clients/players at any given time and the need to facilitate searching of other clients/players inherently requires some type of server environment to begin with.
libpurple along with otr can give you the privacy-over-IM such an application would need.
You could setup a message board on one of the free message board servers so that players can find each other. You'll probably want to encourage them to use private messages to exchange IP addresses. Then, use a protocol that connects using IP addresses. Good luck with that. Firewalls make it a pain.
Then, of course, one machine of the pair would need to act as server, the other as client. Your software must contain both sets of code. I've written such a game and can tell you that the communication code gets a little confusing.
I can tell you right now that you'd be much happier in life if you wrote a web service to facilitate communication. But, then, you'd need a server for that.
Good luck. You're going to need it.
OR, you could just write a game for an IM client, like Microsoft Messenger. I've seen games for that one, so I know it can be done.
As somebody has said, it may not yet possible to do so if you don't have any mediated server between 2 players. As you're happy to use third party server, I suggest that you build your system using Google App Engine + XMPP over HTTP. It works nicely over internet and behind firewall. And yet it's free (as long as your system doesn't grow out of GAE quota).
Peer to peer is out due to your firewall constraint. This doesn't really work easily for directory services anyway.
The next easiest method I would use is to toss up a very simple CGI server script on one of the numerous super cheap web hosting sites. It seems that you don't want to go this route. Is there some particular reason? 100 lines of code and a super cheap server should give you everything you're asking for and more.
I suppose you could hook into some sort of third party chat library thing. I don't know about the current IM protocols, but good old IRC and a separate channel for your game would work. You even could cobble something together using FTP. BLOG comments on a free blog site would work too. The question is why?
These are all kludges. They get the job done in obtuse, inelegant, and poorly scaling ways.
I urge you to reconsider the web server solution.
You have a lot of conflicting requirements. Both clients behind a firewall blocking incoming requests pretty much means they can't do peer-2-peer since neither machine can act as the server, and you will need to have a transport server in the middle somewhere routing messages to each client. Right now what you are asking is pretty much not possible given the no server requirement.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Does anyone know of any SMS APIs that I can use in my web application to send SMS messages to users?
Most mobile providers support SNPP (Simple Network Paging Protocol). Despite the name, SNPP is also used to send text messages to cell phones. It's really easy to use. Just determine which mobile provider each user is using and then dispatch a "page" to the corresponding SNPP server.
For example, Sprint's SNPP server is snpp.messaging.sprint.com:444. The basic process goes like this:
Open a connection to the SNPP server.
Send PAGE The phone number
Check for status code 250 in the reply.
Send MESS Your message
Check for status code 250 in the reply.
Send SEND
Again, check for status code 250
Send QUIT
Some servers also support subject lines and delayed messages, along with two-way messaging.
I think you may have a problem here...
SMS's always end up costing someone, something... You may get lucky and find a provider that has a beta or test account that allows you to send out a handful, but they may not last that long.
I used to use a place that put a 20 character advert on the end of every message, but even they stopped.
Just did a quick google for you and could not come up with any... If you are more specific such as country, you may get better answers...
edit - Just seen someone else answering with a site that looks good! - My comment is based on the UK! I am still not aware of any free provider here.
They're not free, but without a doubt the best supplier I've worked with is Clickatell
http://www.clickatell.com/
They're in over 200 countries, 800 networks and their pricing is quite reasonable. They support REST HTTP/S, SOAP HTTP, FTP, SMTP, SMPP. They also support premium rate messages and MMS to generate revenue.
A while back, smart clients had been touted as the solution to "occasional connected" usage environments, and toolkits like Google Gears have sprouted for the same reason.
It looks to me like constant, reliable Internet access is becoming more and more pervasive (even in places such as commercial airplanes), so my question to the community is this: How relevant are solutions with offline support going forward?
I'm approaching this from the standpoint of a data-intensive enterprise application, such as CRM.
Over the last 3 years I've built 2 separate occassionally connected smart clients.
I've found that adding 'occassionally connected' multiplies an applications complexity (and development time ) by about 3 or 4 times. So it is a very expensive feature to add.
But there are solid business cases for these apps as I'm sure there are for many systems. One was for engineers on the road who often go to client sites where (for whatever reason, security being one reason sometimes) their wireless connection does not work. The user still wants to continue using the system just like they were connected and then have it effortlessly (on their part) synchronize itself once a connection becomes available.
The second app will either be used on a LAN or will have no connection at all, until the user returns 'to the office'.
From a personal perspective I love the idea that with or without an active connection I can continue to 'do my work', indeed even if the connection drops out half way through an activity everything still works and I won't lose any of my data.
Acheiving this seamless connected -> disconnected -> connected etc scenario takes ALOT of work and testing so there must be a very strong business case.
And finally, I think we will never be able to assume that there will always be an internet connection. Whether it be a hardware or service provider failure or some active security blocking connections, at some point in time your users will be in disconnected mode.
I think it depends on the kind of application. For some applications internet access is more relevant than for others, but for general productivity apps I think an offline scenario will stay relevant. Working as a consultant in the software industry, internet access is everywhere, but not every client allows me to connect my laptop to their network.
On the other hand, with 3g and mobile data access becoming affordable, maybe the future will bring us internet anywhere.
Well, reliable internet access is not as widespread as you think if you think globally. Even locally, WiFi isn't even quite as reliable, especially if you are moving from place to place. Building for an occasionally connected scenario gives a greater user experience; I don't think it's always required but it is quite nice. :)