It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I'm developing a two part product. One part is a C# app on a single board computer running Windows Embedded Standard. The other piece is an embedded device running an RTOS with a TCP/IP stack. The two devices need to communicate via an Ethernet cable. It's a point to point connection. Nothing is connected to any outside network.
I'm a bit of a network programming novice, so I'm looking for best practices. I'm making the assumption that TCP sockets is the most straightforward approach. I figured I'd get some advice before writing any code and getting lost.
The one thing that is guaranteed is that the embedded device will maintain a static IP address of 169.254.1.1. That's about all I know. So what do I need to know to get these guys connected? I know there are issues with subnets... but that's where my knowledge is falling short. Which should be the client, which is the server, port numbers etc.
Little more info per request: The two ends are going to be exchanging a pretty simple binary protocol. That part is already defined and it working over an RS-232 link. But the RS-232 port is going away. I want to use TCP to basically carry this information, plus give me all the the good stuff like retries and error checking. Either end of the system can initiate a transfer.
You might want to look into some introduction to socket programming, like http://beej.us/guide/bgnet.
The windows node will have to configure a network interface in the same
subnet as the rtos device and choose a (different) ip address from that
subnet.
Which device is the server and waits for a connection depends on your
application, maybe also on the boot order of the two nodes. For example,
if the RTOS device has booted first, it might wait for a TCP connection
until the other side is ready.
Of course, you'll need some protocol inside the tcp stream. Possibly UDP
might also be an option, if you don't need the features TCP provides. This
might also reduce the memory footprint on the RTOS side.
If the two sides can reboot (or crash :-) indenpedently from each other without
some hardware watchdog taking note, be sure that the other side recognizes the
reboot (e.g. with the tcp keepalive feature), so that you can reestablish the
connection.
With TCP you'll get the reliable connection, but depending on you application,
you might discover that the Nagle algorithm keeps your message latency higher
than what the RS232 setup had. Use the NO_DELAY option on the socket to avoid
this.
I recommend you very much against doing TCP yourself. It is nice but has many hard-to-discover pitfalls for machine-to-machine interface (e.g. naggling, KA configuration, testing the packetizing state machine).
We are in 2012. You can use ZeroMQ and similar [feel free to edit with more and good IP messaging libraries].
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I have been searching for a service that could do something like, notify a user (specific user) that they have a new friend request. I came across SingalR and thought this may be something that might be useful to my application. I see alot of the examples and live uses of SignalR are chat application, which makes sense. Anyway here is what I am trying to accomplish here. I have a MVC social application that uses RavenDB as the datastore, A user may request friendship with another user, I would like to update that client in realtime that they have a new request (something that checks every X seconds). I am either looking for a good SignalR example, or documentation (hopefully example) that may point me in the right direction, or a good service other than SignalR that would suit my app better. Thanks for any answers.
SignalR would definitely suit your app well. JabbR (http://jabbr.net/, https://github.com/davidfowl/JabbR) for instance may be a chat room but it is constantly reaching out to the database to update/retrieve its records.
For your case I'd recommend queuing up a command on database writes to notify other users rather than checking periodically. Meaning lets say user A requests to be friends with user B. First that request is written to the database and then it broadcasts a message via SignalR to all parties involved.
However, if you still would like to implement a timer check every X seconds this is still possible. See ShootR (shootr.signalr.net, https://github.com/NTaylorMullen/ShootR), a multiplayer game that utilizes a game timer and broadcasts collisions when it detects them. Granted ShootR is doing calculations on the server at a much higher interval (50+ times / second) it's essentially the same.
Therefore if you want to take the check every Xs approach I'd suggest taking a hybrid of the two projects (JabbR & ShootR) and implementing a threaded timer (instead of a custom timer used for high frequency updates which is what ShootR uses) and then retrieving data from the database and using that data to send updates to users.
Hope this helps!
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I have a turn-based game in which two players may play against each others.
It's written in C# and uses XNA 4.0.
Currently multiplayer is implemented with TCP/IP. It works pretty nicely, but only if the players are within the same network and one of them knows the IP of the other.
So the question is: How should I implemented the online play for this game? Is TCP a reasonable method for connecting two random players from the opposite sides of the world without them having to deal with IP addresses and ports(or any other such technical details)?
To make this problem more challenging, I have no server for hosting the game matching service. (Well, I have an access to a virtual web server which I could use for sharing the IPs.)
To list questions:
Does .NET offer better choice of communication method than TCP?
What would be the best way to deal with NATs in my case?
Is there a cheap way of getting my own server and run the TCP game matching service there?
TCP vs UDP.
TCP is a bit slower than UDP but more failsafe.
Since your game is turn based it will probably send minimal amounts of data between the client and server and it is not really latency dependant, I would say you might aswell go for TCP.
To make this problem more challenging, I have no server for hosting the game matching service. (Well, I have an access to a virtual web server which I could use for sharing the IPs.)
If you are going to provide your players with a server browser or similar you will need to have a centralized server, a web server with a script/application built for this would do just fine.
Is there a cheap way of getting my own server and run the TCP game matching service there?
A web server or similar host would do just fine and is usually cheap, what you want is:
Function for a server to add itself to the server list.
Function for a client to retrieve the servers on the list.
Doing web requests with C# is no problem at all, the requests could look something like:
http://www.example.com/addToServerList.php?name=MyEpicServer&ip=213.0.0.ABC (adds this server to the list)
http://www.example.com/getOnlineServers.php (returns list of all the servers)
You need to specify what kind of load and latency that is expected and tolerated.
General answer is:
For real time games - UDP.
For scrabble-like-games - TCP.
Use your server to share IP's as you said.
Minecraft uses TCP. It's good for traffic that must be transmitted and received AND can be queued a little.
UDP is a one way error checking. Only the receiving side check for error. This was needed with the older slow ethernet technology where a round trip to check packets is too slow.
TCP is a very reliable protocol with a handshake. So the sending side knows if the data is transmitted sucessfully. But due to the round trip, it puts a lot more overhead and lag on the transmission.
TCP also do arrange packets, which UDP also don't do.
Some games it does not mind losing packets (for example "steaming" data where objects moves around, and it will get updated the next round of packet anyway). There you can use UDP. But if it is critical to get all the data, rather go with TCP, otherwise you will spend a lot of time writing code to make sure that all the data is transmitted successfully.
The networks is quickly enough and the internet being TCP/IP I recommend TCP, except if you really need very low lattency traffic.
This website gives a good summary:
http://www.diffen.com/difference/TCP_vs_UDP
NAT: Should not be a problem just as long as your Time To Live (TTL) is big enough. Every time it get NAT, it's TTL get subtracted by one. When it is 0, it gets dropped
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I'm currently working on a c# online multiplayer game in real-time. The aim is to have client/server based connection using the UDP protocol. So far I've used UDP for players' movements and TCP for events (a player shooting, a player losing life) because I need to be sure such data will arrive to all players connected to the server. I know that UDP is said 'unreliable' and some packets may be lost. But I've read everywhere to never mix TCP and UDP because it can affect the connection.
The main question is how should I organize my network?
UDP is connectionless, how should I save who's is who? Should I save ip adresses of the clients in a list?
Should I use TCP for important events or use UDP? If I need to use UDP, how can I make sure that data will not be lost?
By using both TCP and UDP, I need to save for each player their IP in a list (for UDP) and the TcpClient which is connected in another list (for the UDP). How could I change that to be more effective?
Connections have improved a lot since early game development. In the past the speed advantages of UDP made it a very desirable protocol, even balanced out the reliability issues. However as networks have improved the reasons to shy away from TCP have dissipated.
I would advise picking one of the two protocols and going with it. But mostly because it will simply your network layer and make it easier to debug network issues. When I have to pick between TCP and UDP I make the decision more on how I want my networking logic to flow.
With a UDP based system you do need to do a bit more bookkeeping yourself, but not really enough for it to factor into the decision. A UDP game flows more like independent cells that all happen to share the same world. You don't want a lot of reactive logic (after he does this, i do that), if something is dropped or forgotten the game will keep going smoothly.
TCP will give you much more control. Depending on the API and can involve a bit more setup but its worth the effort. TCP lets you work with a networked partner much like you would work with another thread on the same CPU. There is an overhead with everything that you do but it sounds like you already have it working so might as well stick with it.
I generally tend towards UDP myself because its ingrained I think. Also whenever dealing with networking you have to plan for the un-expected, the lost or delayed packet, and UDP helps drive that message home. If you break that rule you will notice right away with UDP, might not with TCP.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I need to build a server to accept client connection with a very high frequency and load (each user will send a request each 0.5 seconds and should get a response in under 800ms, I should be able to support thousands of users on one server). The assumption is that the SQL Server is finely tuned and will not pose a problem. (assumption that of course might not be true)
I'm looking to write a non-blocking server to accomplish this. My back end is an SQL Server which is sitting on another machine. It doesn't have to be updated live - so I think I can cache most of the data in memory and dump it to the DB every 10-20 seconds.
Should I write the server using C# (which is more compatible with SQL Server)? maybe Python with Tornado? What should be my considerations when write a high-performance server?
EDIT: (added more info)
The Application is a game server.
I don't really know the actual traffic - but this is the prognosis and the server should support it and scale well.
It's hosted "in the cloud" in a Datacenter.
Language doesn't really matter. Performance does. (a Web service can be exposed on the SQL Server to allow other languages than .NET)
The connections are very frequent but small (very little data is returned and little computations are necessary).
It should hold most of the data in the memory for fastest performance.
Any thoughts will be much appreciated :)
Thanks
Okay, if you REALLY need high performance, don't go for C#, but C/C++, it's obvious.
In any case, the fastest way to do server programming (as far as I know) is to use IOCP (I/O Completion Ports). Well, that's what I used when I made a MMORPG server emulator, and it performed faster than the official C++ select-based servers.
Here's a very complete introduction to IOCP in C#
http://www.codeproject.com/KB/IP/socketasynceventargs.aspx
Good luck !
Use the programming language that you know the most. It's a lot more expensive to hunt down performance issues in an large application that you do not fully understand.
It's a lot cheaper to buy more hardware.
People will say C++, because garbage collection in .Net could kill your latency. You could avoid garbage collection though if you were clever, by reusing existing managed objects.
Edit: your assumption about SQL Server is probably wrong. You need to store your state in memory for random access. If you need to persist changes, journal them to the filsystem and consolidate them with the database infrequently
Edit 2: You will have a lot different threads talking to the same data. In order to avoid blocking and deadlocks, learn about lock-free programming (Interlocked.CompareExchange etc)
I was part of a project that included very high-performance server code, which actually included the ability to response with a TCP packet within 12 milliseconds or so.
We used C# and I must agree with jgauffin - a language that you know is much more important than just about anything.
Two tips:
Writing to console (especially in color) can really slow things down.
If it's important for the server to be fast at the first requests, you might want to use a pre-JIT compiler to avoid JIT compilation during the first requests. See Ngen.exe.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I need to control 128 different serial lines via .NET (simply because I know it). I hear there are various Basic Stamps available, and then some XP, CE, Micro, and Embedded options available to me.
/update:
My plan is to have a MUX of some type break down my serial line into a specific address. I'm not planning on having 128 individual serial controllers.
/endupdate
I simply want to have a C# application control a serial port (as directed by an input file of some type) continuously in a loop. If your interested, I'm ultimately controlling 128 solenoids that are either in an open or closed state.
What is the best HW//SW solution for this device? If I have a serial output, I'm planning on having a multiplexer break out the commands to the correct device.
Have a look here:
http://www.moxa.com/product/nport_6650.htm
Converts 32 serial ports to a TCP server with 32 TCP ports.Connect to each COM port, via TcpClient or other suitable TCP client.
Price works out to $51/COM port
Robust and tidy solution.
128 UARTs is a lot and I'd say the issue here is going to be cost. I know of no hardware with anywhere near that - in fact hardware with a "lot" would be something like 8. I know you're saying you want a .NET solution, but to be cost effective, I think a microsontroller is at least worth a look.
Personally I'd probably do a boatload of PICs - maybe on an I2C bus and have some master controller running CE. That would definitely be my first investigation. A quad-UART PIC is less that $5.
If a microcontroller solution isn't palatable to you (and I think it's really the only wise solution), then the only other thing I can think of (and this is an ugly kludge) would be a boatload of USB quad uarts on some ugly daisy chain of hubs. I have no idea what the OS would do trying to load this many drivers - I've never seen it even attempted (and actually never even considered it).
Exactly why are you using serial for this anyway? If the solenoid is eitehr open or closed, that sure sounds like a digital I/O would do - in that case I'd use a few PICs, again on I2C or SPI to drive them via digital outputs.
EDIT
Based on your update, then most any CE device will work. I low-cost eBox 3300 x86 device has a pair. That's going to be something like $260 in qty 1. A ARM-based beagle board has lower power consumption and is under $200, though it doesn't have the nice enclosure.