I am trying to develop my own online game for training purpose.
I have some questions, and I can't find any answers that satisfy me.
Does it exist an online protocol to exchange data between two players? I don't mean TCP or UDP, but a high level protocol. I am looking for a WebService or Remoting with events. I use for now Protocol Buffers, but I need more flexibility (like events). I can develop my own protocol, but I think it exists already a network protocol with events.
I will use the "Command" design pattern or Flex/Bison to parse the query. Is there a better way ?
EDIT
For protocol, I use "protocol buffers".
So I have two options :
Translate my custom protocol into events and callback.
Use a protocol/tool that have already events. Is there such a tool ?
Thank you for your responses.
Regards
Romain
I think you're mixing protocol with protocol implementation. A protocol defines what the messages you send mean and how they are serialized. A message can generate an event at a client but that's an implementation detail.
Related
In what way is HTTP inappropriate for E-mail? How (for example) does the statefulness of IMAP benefit client development?
What actually are the arguments for keeping them separate other then historical and backwards compatibility reasons?
SMTP, IMAP, and HTTP are specialized application-level protocols. If there was a generic application-level protocol which all of these could inherit from, you could usefully refactor things, but since that is not the case, wedging the other protocols into one of the existing protocols is hardly worth the effort, and would hardly simplify things.
As things are now, the history and backwards compatibility is not just a cultural heritage, it is also a long and complex process of defining application-specific features for each protocol. SMTP is store-and-forward, which introduces the need for audit headers (Received: et al.). IMAP was designed for concurrent access to a data store, which is what made it necessary to introduce state (who are you, where are you authorized to connect, which folder are you connected to, what have you already seen, read, or deleted). HTTP is fundamentally a pull protocol (pull down a web page) and the POST facility carries with it a lot of functionality specific to the CGI protocol and the overall content model of HTTP.
SMTP is a protocol that identifies the sender and the recipients to send individual mail messages, each mail server accepts (or not) mail to forward, eventually reaching the destination. HTTP is meant for anybody to connect to the server and look at (mostly the same) contents. They are quite fundamentally different, and so it makes a lot of sense to use different protocols.
What protocols do web cameras use for streaming audio/video feeds over the internet? HTTP? TCP? How is each frame sent inside the protocol? For example, if they use HTTP, does the web cam software encode each frame and tack it on as a query string parameter like:
http://www.some-url.com?encoded-frame=WJDJ84FU84F85594DK3DK
or, is the encoded frame set as the HTTP request's body? Similar question for TCP or any other protocol that is used.
I'm asking because I'd like to stream a web cam to a web server and have software that receives each encoded frame, decodes it, and does something with it. Thanks in advance.
Well the question in OP is open ended because it's not like there is 'one fixed set of protocols(TCP/UDP)' used in this kind of applications and also its scope is large, due to various technologies involved in this end-to-end solution of Camera capturem encoding , streaming, decoding/processing. In the case you mentioned if it is going to be likely that the webcam and the Web server are going to be on same LAN, then well you can as well use TCP/IP and then server can process it. Because on LAN latencies won't be high, so TCP would serve good. Else if on WAN, then UDP/IP can be of help.
There are plenty of tutorials online to get basics of using TCP/IP or UDP/IP sockets and its programming concepts. Then there are tutorials about streaming, packetization etc of Video data.
I don't see how HTTP can be of use here to send from webcam to a server.
For starters
http://streaminglearningcenter.com/streaming-video-consulting.html
Hope this is good to get you started.
I would like to understand what happens when we type "google.com" in our browser wrt OSI model. What all protocols comes into picture AT EACH LAYER any how does they know which one to be used?
Also I would like to know, TCP/UDP which one to be used in Transport layer is decided for network/application? That is for a normal web page like google.com TCP must be used but for video streaming UDP. how is this conveyed to network?
Is the browser also part of this as it is helping. Should it also come under application layer?
Http comes under Application layer of OSI model. now for this particular example, what will come under Presentation and Session layers? Will the sessions be maintained in session layer or HTTP will be doing it on their behalf?
It sounds like you would like a tutorial on TCP/IP. May I suggest a couple of good books
URLs in webpages have a prefix that tells the applications what to do with that link. For instance, ftp:// opens an ftp session, which uses tcp (ref RFC 959 - File Transfer Protocol). As a general rule, the URL prefixes correspond to a standardized protocol, which was specified via RFC. The RFC denotes which transport protocol is used.
EDIT
In the case of youtube, their videos have a http:// URL prefix, but after you make the request, it is redirected to a rtsp:// URL. RTSP can be streamed over UDP.
To answer questions like this, you may find that wireshark is very useful to investigate these things... keep in mind that wireshark works best on wired connections.
Applications don't use any layer of the OSI protocol stack. They use TCP or UDP from the TCP/IP stack, and they 'know which' because of they are programmed to use one or the other or both. The OSI model is obsolete and certainly doesn't apply to TCP/IP.
EDIT: The OSI layer model is a Procrustean bed into which TCP/IP does not fit. You should forget about OSI immediately. It doesn't describe anything in the real world.
Stupid question, but just making sure here:
When should I use TCP over HTTP? Are there any examples where one is better than the other?
TCP is full-duplex 2-way communication. HTTP uses request/response model. Let's see if you are writing a chat or messaging application. TCP will work much better because you can notify the client immediately. While with HTTP, you have to do some tricks like long-polling.
However, TCP is just byte stream. You have to find another protocol over it to define your messages. You can use Google's ProtoBuffer for that.
Use HTTP if you need the services it provides -- e.g., message framing, caching, redirection, content metadata, partial responses, content negotiation -- as well as a large number of well-understood tools, implementations, documentation, etc.
Use TCP if you can't work within those constraints. However, if you use TCP you'll be creating a new application protocol, which has a number of pitfalls.
The idea is to allow to peer processes to exchange messages (packets) over tcp as much asynchronously as possible.
The way I'd like it to work is each process to have an outbox and an inbox. The send operation is just a push on the outbox. The receive operation is just a pop on the inbox. Underlying protocol would take care of the communication details.
Is there a way to implement such mechanism using a single TCP connection?
How would that be implemented using BSD sockets and modern OO Socket APIs (like Java or C# socket API)?
Yes, it can be done with a single TCP connection. For one obvious example, (though a bit more elaborate than you really need) you could take a look at the NNTP protocol (RFC 3977). What you seem to want would be similar to retrieving and posting articles.