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'd like to make an app to send/receive text messages using a GSM modem. However, I've seen that a modem can only receive/send about 8-10 text messages per minute. So if I receive 200 incoming text messages within a 10 minute span (like I'm at a conference and I ask people to sign up), do they get queued up on the modem? Do I have to deal with in in my application? Are they queued up by AT&T (or some other wireless carrier)? Is there a maximum length to the queue? Any help would be great.
Thanks!
You should not have to worry about it.
You can setup the modem to store the messages internally as opposed to on the SIM by setting the preferred storage location to "ME" which will give you whatever memory resources are built into the modem - way larger than whats available on the SIM.
If that fills up, when next the device receives a message it can't handle it will report that fact back to the SMSMC which will record the failure and add the message to a retry queue.
There is no standard for the retry policy, so they may retry a few minutes later, gradually increasing the interval as failures build up upto a total retry time equaling the "validity period" setup on the senders handset, or their own upper limit.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I want to transfer some files from one point to another. Files are sensitive so transfer has to be reliable, but if I use TCP to transfer files than the speed gets slow.
How do I create a reliable version of UDP that will transfer files quickly?
What I am doing is sending an acknowledgement for every received packet. But it is reducing my transfer speed.
Is there any way that exists without sending an acknowledgment for every received packet? Can I somehow keep track of lost packets efficiently and request those packets only?
Note:: I am sending a sequence number with every packet
I guess that you could put a count value in each packet and if you received a packet that skips a value then you know that you've lost one or more and could request a resend.
However, you're starting to implement the functionality of TCP by coding for packet loss. Is there a reason why you couldn't implement that instead?
Certainly if I was transferring sensitive data I wouldn't choose UDP myself.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I am trying to understand how the timestamp in rtp along with some time synchronization protocol like ntp, can synchronize the media streams. Based on my understanding I have drawn this. Please correct me if I'm wrong.
Here clock in these devices are synchronized, and rtp packet is created with timestamp 10. But due to network transmission delay the packet reaches at 11, but the timestamp is still 10. How this case is handled in rtp for proper synchronization or is it the application that is taking care of this situation?
When handling an incoming (UDP) RTP stream, received RTP packets will be buffered before they are processed. This is to allow for jitter and such. This buffering period is typically between 50 and 300 milliseconds, depending on the used network topology.
If the buffering time is adjustable at runtime, you could use this buffering period to synchronize the two streams by ear. When two streams are out of sync adjust the buffering time (delay) of one of the streams until they appear in-sync.
If you don't want, or can't, adjust the buffering period by ear you should use RTCP (RFC 3550) to synchronize the two streams. You can't just use the timestamp values in the RTP packets.
I think this website with FAQs on RTP can be helpful.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
i'm working in a simple project on my raspberry pi, which flash some leds in differ ways on some system events (like disk reading, ethernet communications, processor overload), and these leds need to be shut off some time after system is idle (these leds will behave varying their intensity when no sys activity detected).
To achieve idle detection, i'm using XScreenSaver, until here, everything works flawlessly.
As my project needed to be executed as daemon (etc/init.d) and needed to run with root privileges (because the pigpio library) the communication with X Server (via XOpenDisplay) is returning NULL every time, even when system is ready and in graphical interface. On terminal, running this manually, everything works perfectly.
as my research goes, i've understood that isn't possible to access X Server when there is no console available at boot time, and there is no way to access it for security reasons.
so i ask, how i could achieve this (detect idle time) on a simplest way possible? ( i tried self restart, tried setting DISPLAY variable on start script nothing seems to work.) I'm new on linux development and can't figure how to properly solve this.
Just awnsering my own question, if anyone having the same issue as me.
Detecting System Inactivity (Idle) outside X graphical interface, is just a matter of USB Keyboard / mouse activity by monitoring their IRQs (usually IRQ 1 /IRQ 12) on /proc/interrupt or more easy (supporting other USB Input like even Joysticks!) by monitoring /proc/stat on "softirq" line, second numeric column that contains numeric amount of bytes transferred when these devices has some / any input (mouse moving or key pressed / released)
This achieved easily in C by time to time, fopen / fread on these fields comparing the values with old ones.
Thanks a lot to my intensive researchs on Linux internals & User Olaf that have a huge knowledge on discover the obvious.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I've been dying to implement a chat server in C and Winsock for a long time now, but I haven't taken the time. Partly, because I'm still unsure of some of the conceptual ideas about building a server on Windows OS'es for something like chat.
Here are some of the issues I've been thinking about :
How will user x connect to my server over a generic LAN
without me relying on them to type in a network address( e.g. address
could be invalid, redirected to a different server, etc. )
If I use broadcasting to solve the above problem, will that be reliable enough for chat?
Will that potentially DDos a LAN since the packets will be be forcibly handled on every machine and may take a lot of bandwidth if enough people join?
What is the difference between multicasting and broadcasting? Is multicasting truly superior?
Etc.
Per request, my definition of reliability would be that I can get most of the data consistently in sent packets. In other words, I don't mind a few dropped packets, but I do mind if the data gets messed up quite a lot along the way.
Currently, I have a lot more questions than answers, but the main point I'm getting at is this :
What is the safest and most reliable way of implementing a chat over a LAN in C and Winsock?
How will user x connect to my server over a generic LAN without me relying
on them to type in a network address( e.g. address could be
invalid, redirected to a different server, etc. )
Use a closed list of known servers, or use some broadcast based autodiscovery system.
If I use broadcasting to solve the above problem, will that be reliable
enough for chat?
Define your requirements for reliability.
Will that potentially DDos a LAN since the packets will be be forcibly
handled on every machine and may take a lot of bandwidth if enough
people join?
It's a chat... the amount of generated packets will be comparatively short and small.
What is the difference between multicasting and broadcasting? Is
multicasting truly superior?
Search the web. There are lots of resources and information about multicasting, most precisely, IP multicasting. In short:
Broadcast delivers to all hosts on a broadcast domain. Multicast delivers to all hosts that have explicity joined a multicast group, which may not be in the same broadcast domain (see last point).
Broadcast forces a switch to forward broadcast packets to all its interfaces. Intelligent switches can benefit from peeking at IGMP packets to know which interfaces multicast packets have to be forwarded to.
Broadcast cannot treepass a broadcast domain. Multicast packets can traverse a router, if it's configured to route multicast (search for M-bone)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I have to create a functionality for my project like saving session and further resume it from the same position in future. So I need to know how save the state of a process and then read from disk and resume it afterwards.
PS. The application is an interactive shell for a language and I need to extend it include a save session and resume session. But we want the code to be generic enough to be used in other places too.
This is quite a challenging task. The basic idea is to interrupt the process with a signal, at which point the OS puts the state of all registers (including the instruction pointer) in memory where you can access them if your shell has spawn the process you want to interrupt.
For more detail, you can look how checkpointing utilities handle that problem:
dmtcp
BLCR
Criu
That is quite hard to answer in general other than “save the program's entire state to a file and load it from there on resume”. That can be very tricky because you might need to restore things like file handles and sockets, which may not even be possible if things have changed during the suspended state. But it may suffice for you to support something less than that and only save the information necessary to approximate the previous state (e.g., save the list of program files to load, or the save user's command history and replay it, etc).